PSM I Exam Simulator 1

All these choices are the correct criteria for deciding the duration of a Sprint.

We have only just three roles in Scrum: Product Owner , Scrum Master , and Development Team . It’s not permitted to define new roles and the Development Team must be self-organizing and cross-functional.

When the item is complete based on the Definition of Done, therefore the real and final users can use it, which also means an Increment of working software which is potentially releasable has been created.

The Scrum Master is responsible for helping everyone understand Scrum theory, practices, rules, and values. Removes impediments (solves problems), facilitates the meetings as needed. The whole Scrum Team decides the Sprint length considering one month for the maximum duration. Tasks are assigned by the Developers themselves.

Adaptation, Transparency, and Inspection are the Scrum Theory Pillars. Scrum as Agile framework, is mainly about adaptation (instead of prediction).

Despite the Scrum Master doesn’t manage people, he manages processes. That’s why it’s considered a management role. The Development Team is self-organized; the Scrum Master can coach and help but the developers are who handle the progress and performance of the Sprints. It is the Product Owner who owns the Product Backlog.

The Development Team is cross-functional and does the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. They don’t use any external help. Is not recommended, nor is a good practice, for the Scrum Master or Product Owner working as developers.

The decision on the order of items can be influenced by a committee, the customer, or any other stakeholder, but only the Product Owner decides what makes the most sense to optimize the value of the work being done by the Development Team.

Since people who actually do the work are the ones who best know what is needed to complete specific tasks; all estimates are done by the Development Team.

The Product Owner is the sole person responsible for managing the Product Backlog but always can and must consider the feedback and opinion from other stakeholders including the Development Team who can influence to add new items in Product Backlog. Good requirements should be brieg enough, that’s why acceptance tests can be used to express many of the details that result from the conversations between customers, users, Product Owners and developers, including non-functional requirements. One product only has one Product Backlog.

Being self-organized implies that the team follows its very own process, rather than receiving orders. When it’s so, the members of the team tend to commit themselves and increase their accountability, and creativity.

There’s no hardening Sprint, Sprint zero, integration Sprint, release Sprint, etc. There’s just one type of Sprint, and its goal is to create an Increment of potentially releasable valuable features.

Product Owners should communicate effectively with the customers therefore also engaging them.

This shouldn’t be often because it creates a short time reduction in the productivity, but if needed, try to avoid team members changes during the Sprint.

Every team tends to learn more and mature during the project, so the techniques, expertise, skills and methods improve too. This must impact on the definition of Done.
All Scrum roles, events, and artifacts are necessary and shouldn’t be omitted for any reason.

Remember that Development Team is self-organized. Therefore, It is team’ responsibility to measure its own productivity and performance throughout the Sprint, figure out its own process, plan, estimate and optimize the work required for items and the Sprint Goal, and to resolve their own conflicts.

One the main responsibilities of the Product Owner is to maximize the value of the Development Team’s work, and he’s the only one who can add new items to the Product Backlog. Even when the Development Team owns the Sprint Backlog, the members don’t add items arbitrarily, the Product Owner must make sure that any new item adds value and she or he can work with proper stakeholders about it and then add it to the Product Backlog for the next Sprints. Also, the Product Owner can reject the new feature, rather than the Development Team.

The only one who can cancel a Sprint is the Product Owner. This can happen when he realizes that the Sprint doesn’t make sense anymore, because the Sprint Goal has become obsolete.

The agreed definition of “Done” for the Scrum Team, is used to assess when work is complete on the product Increment in order to deliver an Increments of potentially releasable functionality.

The Sprint Retrospective occurs always after the Sprint Review and prior to the next Sprint Planning.

The purpose of the Sprints is creating increments; in other words, a piece of working product which is potentially shippable and based on the agreed Definition of “Done”, regardless of the techniques, documents or methods used to achieve this.

The Development Team owns the Daily Scrum meetings, they can be conducted in different ways but always focuses on progress toward the Sprint Goal.

The only ones who must attend are the members of the Scrum Team. The Scrum Master ensures that the Development Team has the meeting but he doesn’t need to be present at the meeting. Anyone else can attend but don’t “must” be there, and notice that the guests only watch and listen they don’t participate.

The whole Developer Teams share the Sprint Backlog items ownership and their tasks; these tasks assigned to the Developers by themselves. Also, all members of the Developer Team share the accountability of their own tasks.

When we have shorter Sprints, there are more opportunities to show progress, and receive feedback, validate our knowledge and therefore Adapt. So, shorter Sprints are preferred when we have higher risks.

The main purpose of the Sprint is to create an increment of useable, and potentially releasable “Done” product.

It’s the responsibility of the Development Team to select the appropriate number of Product Backlog items, break down the tasks and create estimations for them each Sprint.

The Product Owner is responsible for measuring project performance. The Development Team only measures the performance of the current Sprint.

The Product Owner sets the objective that the Sprint should achieve although can be influenced by the Development Team. However, only members of the Development Team create the Increment, that’s why only they pull the Product Backlog items in order to accomplish Sprint Goal.

The Scrum Master must coach the whole Scrum Team members in organizational environments in which Scrum is not yet fully adopted and understood to practice agility. The Scrum Master must help them to effectively communicate each other, but be careful, don’t act as a go-between for them.

Even if the team doesn’t deliver increment the Product Owner must be informed about it, and s/he must work with the Development Team and adjust, add, and/or remove Sprint Backlog Items thoroug the Sprint in order to achieve the Sprint Goal. But, since this is still the Sprint Planning we also still have the chance to modify de Sprint Goal, we won’t able to do so after the Sprint Planning.
We always work on a regular and constant pace, we shouldn’t work overtime.
We shouldn’t change the number of developers, adding developers won’t increase productivity in short term.

The Definition of “Done” defines what is expected as result of the current Sprint. This include (but not limited) to acceptance criteria and non-functional features. The purpose is to share the same understanding of the completed work to increase transparency.
The Sprint Goal is what defines the purpose of the Sprint.
The Development Team must have present that the Definition of “Done” to create tasks, but also the description of each pulled Product Backlog items.

We need to know when an item is really Done, in other words, we share a common understanding of what means a finished job. With this purpose, we can increase Transparency when there are tests included in the Definition of “Done”, which will verify how close is the work of being “complete”, “potentially releasable” and becoming a real Increment usable for final users.
Also writing acceptance tests help to express many of the details that result from the conversations between customers and Scrum Teams, rather than writing long lists of “The system shall…”.

After de Sprint Planning the items pulled from Sprint Backlog can’t be changed. But the broken down tasks created by de Development Team to complete the work are always changing and adapting according to their practices, techniques, and knowledge.

Multiple Scrum Teams should use the definition of “Ready” to normalize estimations. This way it will be easier to measure and compare their performance

There are no comparable estimation units between the Development Teams, each team is different. If you try to normalize, you can lead to misunderstandings and padding problems.
Definition of “Ready” is a common practice but is not part of the Scrum guide, and its purpose is neither to normalize estimations nor performance measuring.

The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team and prioritize the Product Backlog items accordingly.
There is no role of Project Manager or equivalent in the Scrum framework.
Product Owner can be dedicated part-time to one project.

If a project does not include Scrum Master or Product Owner roles, this project is not doing Scrum. Both roles can be part-time but always are performed in a Scrum project. One of the must important Scrum Master activities is removing impediments, and it doesn’t matter how mature is the Development Team, its members will be always benefited when someone takes care of these issues.

Scrum does not do upfront planning, only a few tasks broken down from the items are created in the Sprint Planning.
The Development Team is self-organized, their members decide who does what.
There is no baseline for a Scrum project.

There’s no such thing as Sprint zero. The first Sprint is the first one, and it’s not different from other Sprints, from the perspective that the Developer Team should create an Increment. The infrastructure, tools and requirements are prepared gradually throughout the project.

The Development Team neither analyze, design nor describe the complete architecture and infrastructure, beforehand for the whole project. Agile processes are characterized by frequent short bursts of design, just enough to reach the Sprint Goal.

No one can remove or change the Sprint Backlog items when the Sprint Planning is finished. The only exception is when there’s still time and the team has completed all items, in which scenario they will pull the next item from the top of the Product Backlog.

Scrum is not a methodology or body of knowledge, is a framework. A lot of organizations start implementing Agile in a cultural context that is mostly non-Agile.This creates tensions and frictions that the teams adopting Agile have to deal with.
According to the Scrum Guide, a Sprint is a time-box of 4 weeks maximum (can be less).

Many nonfunctional features, like security, can be added as acceptance criteria and tests in the Definition of Done to be applied to all or some Product Backlog items.
We can have some specic security concerns that can be items in the Product Backlog.
The Development Team is crossfunctional and self-sufficient, should be capable of taking care of every aspect of the product, including security.

When Product Backlog is created, items are added to it. They have different sizes and eventually are ordered on their business value. The most valued items will be on the top and usually, these items would be broken down into smaller ones. We don’t do this with those items on the bottom. That’s why usually larger and less clear items are on the bottom of the Product Backlog.

The Product Backlog items are ordres accordenly based on their business value. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering. The Product Owner can consider items size and risk, but among others, these are only criteria to stablish final value. Items should be independant from each other, in order to facilitate their ordering.

Every increment should be potentially releasable and completed based on the Definition of Done. However, increment doesn’t have to be actually released. The Product Owner decides if make sense to release or not.

Removing impediments and facilitating Scrum events as requested or needed is the kind of thing expected from the Scrum Master. The development team is self-organized; the Scrum Master does not give them orders. The Scrum Master must ensure that the Product Owner knows how to organize the Product Backlog to maximize value, but the Scrum Master is not responsible for doing it.

Only members of the Development Team create the Increment and are the best suited Scrum Team members to do estimations. The Product Owner and the Scrum Master can suggest and use techniques to help the development team to measure their effort, however, only the Development Team does the estimation itself.

The infrastructure and tools are prepared gradually throughout the project, and the Sprint Goal and Definition of Done should be realistic and created accordingly.

Scrum is a framework which is adaptative and empirical rather than theoretical, thus it can be used for the development of complex products in complex environments. Scrum is more about project delivery than project management, therefore is neither a methodology nor body of knowledge.

– There’s only one Product Backlog and one Product Owner for one product. Each team needs to have a separate Sprint Backlog however.
– The Development Team is responsible for selecting the items from the Product Backlog, however, they can select representatives to do so. They share ownership on these though.
– Team members can change the composition of teams (shift) between Sprints.
– Even though Product Backlog items should be independent of each other, the dependencies between teams are unavoidable in scaled Scrum and they need to be handled.

Scrum doesn’t describe any detailed step, and rather than a methodology is a framework.

Developers should be self-organized and they’re responsible for teams formations and composition.

The Scrum values named in the Scrum guide are Commitment, Courage, Focus, Openness, Respect. The Scrum Theory Pillars are Transparency, Inspection, Adaptation.

The Scrum Theory Pillars named in the Scrum guide are Transparency, Inspection, Adaptation. The Scrum values are Commitment, Courage, Focus, Openness, Respect.

Cross-Functional means that the professionals in the Team Development should have the all the expertise to do the necessary work in order to deliver a potentially releasable Increment of “Done” product at the end of each Sprint.

The Development Team is Self-Organized, therefore this is a decision and responsibility of its members. Of course, the Scrum Master must address and support this decision since is also an impediment.

The Development Team is self-organized, hence its members decide on the way they work and on the technical approach of the project.

Infrastructure and tools are not prepared upfront, because it requires a complete understanding of the whole project and product, which is usually not the case, so we need to hold on to the adaptation pillar. The required infrastructure and tools will be prepared gradually through the project, because they depend on the product we’re going to create, which in turn is defined through the project.

We can’t change the Sprint Goal, however, the team can talk and negotiate with the Product Owner in order to add new Sprint Backlog Items as needed.

Scrum timeboxed events are not extendable, you can take the available time for some these events as maximum duration, so they can be finished earlier if everything is done, but Sprint timeboxes have a fixed duration, this means they can not shrink. If everything is finished before the end of the Sprint, the Development Team will pick the next item from the Product Backlog and starts working on that.

User Stories, Use Cases, Tests, Tasks and even other elements which help to define and clarify the work can be part of the Sprint Backlog.

The trend line gives us visibility about the forecast for the finishing date, considering a constant development team Capacity for the Sprint Backlog.

The Development Team is responsible about its members because it’s self-organized, this means its member decides about removing any member from the team. Since this situation is actually an impediment, the Scrum Master can help the team.

Agile principles support processes which promote sustainable development, this means that every person related directly to a project should be able to maintain a constant pace indefinitely.

Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

The Scrum Master serves the organization in several ways, including leading and coaching the organization in its Scrum adoption, planning Scrum implementations within the organization, also the Scrum Master serves the Development Team in several ways, including, removing impediments to the Development Team’s progress.

Certainly, the Sprint Backlog contains the selected Product Backlog items but also contains the tasks for the current Sprint.

The Sprint Planning priority is answering two questions:
What can be delivered in the Increment resulting from the upcoming Sprint?
How will the work needed to deliver the Increment be achieved?
The team doesn’t need to get all the detail about every task as long these questions are answered and the pending definition can be completed as soon as possible in refinement activities.

The Sprint Goal and Sprint Backlog are created during the Sprint Planning meeting.

The Sprint Review event is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. Attendees also collaborate on the next things that could be done to optimize value.

Everyone in the Scrum TEam must understand what “Done” means. Although this may vary significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.

Sprint Zero doesn´t exist in the Scrum framework and all the Sprints should be able to create an Increment of working software. The Inspections and Adaptation concepts are about making adjustments gradually through the project, this includes infrastructure and tools.

The Product Owner owns the Product Backlog and is the sole person responsible for it. The Product Owner does Product Backlog management, this includes:
• Clearly expressing Product Backlog items.
• Ordering the items in the Product Backlog to best achieve goals and missions.
• Optimizing the value of the work the Development Team performs.
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next.
• Ensuring the Development Team understands items in the Product Backlog to the level needed.

The Sprint Review is at most a four-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. During this event, the Scrum Team and stakeholders collaborate about what was done in the Sprint, so is an opportunity for inspection and adaptation.

There’s no such thing as Sprint Hardening Sprint. We have a Sprint 1, Sprint 2 and go on, a surprise additional Sprint or a planned buffer sprint is not in alignment with Agile principles of timeboxed development to create a potentially shippable product. If the stories are correctly prioritized, the Definition of Done is unambiguous, and the product backlog is regularly refined based on business priorities, the teams should be able to complete the development tasks.

The Product Owner is responsible for getting buy-in, understanding the stakeholders’ concerns and goals. The Product Owner communicates and represents the desires of the client.

The Scrum Master serves the Development Team in several ways like:
• Coaching the Development Team in self-organization and cross-functionality.
• Helping the Development Team to create high-value products.
• Removing impediments to the Development Team’s progress.
• Facilitating Scrum events as requested or needed.
• Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

The purpose of all Sprints is to create an Increment of “Done” work, a piece of working software usable and potentially releasable, however team doesnt need realese every Sprint, but eventually, the team must release its work.