PSPO I Exam Simulator 1

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

Since items in the bottom are no high priority because their lower business value, won’t be developed soon, therefore there’s no need to spend too much time adding nor clarifying detail to them; that would be some kind of upfront planning.

A new Sprint starts immediately after the conclusion of the previous Sprint.

The Product Owner role is not a full-time job, and the amount of time requires depends on the project and its environment, however, they need to spend as much time as needed to do all their responsibilities, which are among others maximizing the value, setting priorities on Sprint Planning, answering questions during the Sprint and refactoring, helping developers adjust their work.

The Product Owner manages Product Backlog against the assumption that value will be generated. This assumption remains invalidated when not checked against users and market.

Scrum users must frequently inspect Scrum artifacts and progress to detect undesirable variances. The primary tool for the Product Owner to uphold transparency is the Product Backlog. Product Backlog is a living artifact that is actively maintained and updated to reflect reality. At the Sprint Review, attendees collaborate on the next things that could be done to optimize value, which is processed into an updated Product Backlog.

Value is likely to vary across products and organizations.

If the definition of “Done” is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum. The Development Team of the Scrum Team can complement it with elements specific for the product or context.
If “done” for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of “done” appropriate for the product.

The Product owner clearly expresses Product Backlog items, ensuring the Development Team understands items in the Product Backlog to the level needed for developing them and creating the value the Product Owner envisions. Scope may be re-negotiated if the effort grows much higher than anticipated.

The owner of a product is not only accountable for the development and release of a product, but also the cost of maintaining and operating the product. If a person ‘owns’ the product, he/she can be expected to be responsible for the complete lifecycle of a product.

A first Sprint requires no more than a Product Owner, a team, and enough ideas to potentially complete a full Sprint.

Indications of value on Product Backlog are useful but are only a prediction until validated against users and market

A Product Owner engages actively and regularly with stakeholders. However, to limit the disturbance to the development progress and keep focus high, the stakeholders have a formal role in the process at the Sprint Review only.

The Product Owner manages Product Backlog against the assumption that value will be generated. This assumption remains invalidated when not checked against users and market. When a Sprint’s horizon is too long, you increase the risk that what is being developed may no longer be desired. Sprints limit risk to one calendar month or less of work.

Various projective practices upon trending have been used to forecast progress, like burn-downs, burn-ups, or cumulative flows. These have proven useful, but none are mandatory and care should be taken because none can replace the importance of empiricism. What will happen is unknown, no matter what has happened.

The Product Backlog is dynamic; it constantly changes to identify what the product needs in order to be appropriate, competitive, and useful. Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. The primary tool to do so is the Product Backlog.

For the Product Owner to succeed, the entire organization must respect his or her decisions. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.

Scrum users must frequently inspect Scrum artifacts and progress to detect undesirable variances. The primary tool for the Product Owner to uphold transparency is the Product Backlog. Product Backlog is a living artifact that is actively maintained and updated to reflect reality. At the Sprint Review, attendees collaborate on the next things that could be done to optimize value, which is processed into an updated Product Backlog.

It’s up to the developers to find their way and ensure that their outputs will create an integrated Increment that is potentially releasable.

Technical debt is the consequence of poor system design and architecture, and/or related inconsistent processes. This is because the team doesn’t refactor, or have a poor definition of “Done”. If the technical debt keeps increasing, the development will become harder day after day, and it will slow down the progress on one hand, and even create problems for releases on the other hand.
The Development Team should apply continuous refactoring, and/or the whole Scrum Team must review issues with the definition of “Done” (standards not included on time, incomplete acceptance criteria, etc)

Sprint Planning serves to plan the work to be performed in the Sprint. This plan is created by the collaborative work of the entire Scrum Team. Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. What can be achieved in this time-box may be influenced by additional practices that are however not prescribed by Scrum.

Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. If a product isn’t released, the opportunity to capture user and market feedback is lost.

The Development Team is responsible for all estimates. The people who will perform the work make the final estimate.

The Product Owner represents the stakeholders to the Scrum Team. This typically requires active interaction in order to be able to represent stakeholders and their needs.
Product Backlog refinement is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items.

The Product Owner is responsible for maximizing the value of the product. How this is done will vary widely.

The Product Owner is responsible for ordering the items in the Product Backlog to best achieve goals and missions, thereby optimizing the value of the work the Development Team performs. How this is done, and what value means, may vary widely across organizations.

The Product Owner manages the Product Backlog against the assumption that value will be generated. Indications of value on the Product Backlog are useful but are only a prediction until validated against users and the market.

The Product Owner represents the stakeholders to the Scrum Team, which includes representing their desired requirements in the Product Backlog. The Product Owner has the final call over the Product Backlog.

All 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. The Increment reviewed at the Sprint Review must be useable, so a Product Owner may choose to immediately release it.

A traditional project manager is responsible for all aspects of a project; costs, resources, execution, release, planning, capacity. Scrum is a framework for complex product development, regardless of whether the work is organized in projects. The Product Owner is responsible for maximizing the value of the product and the work performed, a responsibility that is complemented by the specific accountabilities of the Development Team and the Scrum Master.

The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Backlog evolves as the product and the environment in which it will be used evolves. Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. As long as a product exists, its Product Backlog also exists.

The Product Owner manages the Product Backlog against the assumption that value will be generated. This assumption remains invalidated when not checked against users and the market.

During the Sprint scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage. The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. In the absence of a Product Owner, the latter accountability is not performed.

It’s the responsibility of the Development Team to estimate the amount of work of Product Backlog items and to select the appropriate number of them for each Sprint. They also break down the items into tasks during the Sprint.
Measuring the project performance is the responsibility of the Product Owner while measuring the Sprint performance is done by the Development Team.
Creating new Product Backlog items, ordering them (prioritization), and making sure that everyone has a clear understanding of them is the responsibility of the Product Owner.

Increased Velocity is desired, also is good to have visibility of our current Capacity but these metrics are not directly connected to value and can be misleading. WIP is a measure of how much work the team is doing at one time, it’s not used to measure value.
User/customer satisfaction is important. It’s not an abstract measure like lines of code or velocity.
There are several methods and some KPIs for measuring the value of the releases, and when improved, will show our success.

The team having a lot of features to complete doesn’t guarantee that they include the most important ones.
Even more, having more features at the wrong moment may increase the maintenance cost and other efforts, which decreases the overall value.

The Product Owner’s main purpose is accountability for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary across organizations, Scrum Teams, and individuals.

The responsible for the Definition of Done is the Development Team rather than the Product Owner.

Estimating is total responsibility of the Development Team by default. The Product Owner doesn’t choose to delegate it, because s/he hasn’t such authority in the first place.

You don’t have to have all the items identified before starting the first Sprint since Product Backlog is a dynamic and live document. However, the chosen items as part of the current Sprint objective must be clear for development whatsoever.

When the Sprint is canceled, the Product Owner reviews the completed items and typically accepts those that are “Done”. This is so because there’s no added value in putting them back to the Product Backlog and then to another Sprint Backlog when there’s nothing left to do for them.
Whenever an item is not done during the Sprint (for cancellation or reaching the end of the timebox), it would be moved back to the Product Backlog, rather than the next Sprint Backlog. This is so, because the Product Owner might reorder them, and they won’t be on the top of the Product Backlog anymore.

Only the Product Owner can order the Product Backlog. This can be influenced by other stakeholders, but the Product Owner always has the final say.

In order to provide value, the Increment must be usable, this is why an increment may be released only if makes sense.

A burndown chart is a graphical representation of work left to do for a given period of time. When this tool is used by the Scrum Teams, is used to track the product development effort remaining in a Sprint.

All teams should be cross-functional, with 10 or fewer members.

It is OK if some of the items are not done until the end of the Sprint. What we have in the Sprint Backlog is our best guess on what we can deliver. If there’s pressure on the developers to finish everything, they will start adding margins to their estimates, which turns into less productivity because of Parkinson’s law.
When the Development Team realizes they cannot finish everything, they get help from the Product Owner to adjust their work (tasks), to ensure they will deliver maximum value by the end of the Sprint.
The Product Backlog items in the Sprint Backlog are not added or removed during the Sprint.

Scrum doesn’t use upfront planning and design, and what is described in this question is a form of upfront preparation.

The Product Backlog is a dynamic concept, that is not completely composed at the beginning of the project (or any other time), and is never made static by baselining.
The Product Backlog always changes to reflect the feedback from the customer, end-users, market, and their environment.
It’s fair to say that the whole framework is designed in a way that enables such a responsive Product Backlog.

The Product Owner is accountable for effective Product Backlog management and maximizing the value of the Scrum Teamwork, knowing and understanding which the needs of the business are.

The Product Owner is responsible for spending enough time with the developers to make sure the items are clear and understood.
The Daily Scrums are only for the developers. Others may attend, but they won’t participate.

When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “˜Done’ means. Scrum Team members must have a shared understanding of what it means for work to be complete, to ensure transparency and is used to assess when work is complete on the product Increment. This Definition of Done provides the team guidance on what it takes to make the increment shippable.

“Baselining” is a term used in traditional environments for referring to a finalized upfront plan that would be followed in the future, and used for evaluating the actual performance. There’s no upfront planning and no baselines in Scrum.

The Product Owner is responsible for measuring the progress of the project and tracking the remaining work in the Product Backlog.
The Development Team is responsible for measuring the progress of the Sprint and tracking the remaining work in the Sprint Backlog.

The Product Owner can delegate his/her responsibilities to the development team, but s/he stays accountable.

All teams can use the same definition of “Done” but, if that makes sense, they can have different definitions as long as they are compatible and capable of creating integrated Increments. So, the teams don’t “must”, but they “may” have different definitions of Done.

The same person can play more than one role; e.g. Product Owner and developer. However, this is not recommended.

The Product Backlog items in the Sprint Backlog do not change, but another element in the Sprint Backlog is the tasks, and they are always changing.
This is the responsibility of the Development Team to make changes in the Sprint Backlog tasks; while they may also “consult” the Product Owner for this.

Product Owner is not a full-time job, and the amount of time required depends on the project and its environment. They need to spend as much time as needed to do all their responsibilities, which results in maximizing the value.
Note that the only reason for the Product Owner to spend time with the developers is not refinement, but also Sprint Planning, answering questions during the Sprint, helping developers adjust their work, etc.

There are no hardening Sprints in Scrum. All Sprints are the same and create Increments. Activities dedicated to stabilizing the code base or “Hardening” is done during all Sprints.

Managed conflicts can be helpful to the project. Through proper conflict management, team members learn more about the project goals, project details, create or improve ideas and interact with each other in a productive way.

Technical debt is shortcomings in the code that makes it less than “good enough”, and therefore creates risks in the future. It usually decreases velocity in the future (because the team has to fix the shortcomings), and as some of the debt might remain in the final product, the maintenance cost will increase as well.
The total cost of ownership is a combination of the project cost and maintenance cost.

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

A self-organized team is a team that is able to self-manage and decide how best to accomplish their work.

This is an easy question. But be careful, it has multiple answers, a question might seem easy but you can choose wrong or in an incomplete way, just because you didn’t read it carefully.

Designing the software is part of the development and should be done by the developers. They are self-organized and make technical decisions, and volunteer for tasks (assign them to themselves). Estimation is the responsibility of the developers, because they are the people who will develop the item. The rest are done by the Product Owner.

At the end of every Sprint, an increment of “Done” work must be available in order to inspect and adapt properly.
Scrum is based on empirical process control and asserts that knowledge comes from previous experience and making decisions based on what is already known. Scrum employs an iterative, incremental approach to optimize predictability and control risk.

The Product Owner is in charge of setting the overall vision for the product and ensuring that it aligns with business goals. However, the Sprint Goal is prepared during the Sprint Planning, by the whole Scrum Team.

Sometimes organizations can use a definition of “Done” for all projects. Otherwise, the Development Team would be responsible for creating one.
Even when there’s a definition of “Done” in the organization, it can be used as a minimum, and the developer can add extra elements to it.

The Sprint Retrospective is the last event in the Sprint. It is timeboxed to a maximum of one-month Sprint, and all Scrum Team members attend it.
Its purpose is looking for improvements in the individuals, interactions, processes, tools, and their Definition of Done (the way the Scrum Team is working), problems faced, etc.

The Product Owner can delegate his/her responsibilities to the development team, but s/he stays accountable.

Velocity and value are not related directly. Value is the benefit to cost ratio. Since we start with the most important items first, those
remained for the 6th Sprint are expected to have less value compared to those delivered at the 4th Sprint.

During the Sprint, the Product Backlog items in the Sprint Backlog would not be added or removed, but as more is learned, the scope may be clarified and re-negotiated between the Product Owner and Development Team. This is mainly focused on the interpretation of the Product Backlog items and the tasks created by decomposing them.

In complex domains, you are only able to know the outcomes in hindsight. Empiricism, from which Scrum was founded, asserts that knowledge comes from experience and making decisions based on what is known. New knowledge will emerge as work is being done.

All Scrum events are necessary; they should never be removed.

The “cone of uncertainty” is about the fact that uncertainty is highest at the beginning of the project, and reduced as we progress. This uncertainty can be about the duration, requirements, etc.
The “cone of uncertainty” is no part of the scrum framework, but is another tool/technique that can be used.

The Product Owner can delegate his/her responsibilities to the development team, but s/he stays accountable.

The Product Backlog refinement is done by the Product Owner and the Development Team. The common practice (not a rule) is that it shouldn’t take more than 10% of the developers’ time. The Product Owner spends as much time as required on refinement.

Burn-down charts are very common for tracking and representing progress, but they are not mandatory, and the Product Owner can use other tools/techniques as well.