Who is part of the discussion about which Product Backlog items are selected for a Sprint vce

Who’s responsible for maximizing the value of the software product you’re working on? Who’s responsible for the work of the software development team? The CEO? Head of Engineering? PMO? Software Development Manager? In Scrum, the responsibility lies with the Product Owner. In this article, I’ll detail all those things that a Professional Product Owner does and hope to convince you just how important they are to a successful Scrum implementation.

This article is almost entirely based on the content of the Scrum Guide. I’ve simply re-presented the information in a way that new Product Owners would find useful. For a fuller understanding of Scrum, please read the guide. It’s available free and, at only 16 pages long, is a model of brevity.

Section 1 – Job Description for a Product Owner

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

• Clearly expressing Product Backlog items;
• Ordering the items in the Product Backlog to best achieve goals and missions;
• Ensuring 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; and,
• Ensuring the Development Team understands items in the Product Backlog to the level needed.

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a backlog item’s priority must convince the Product Owner.

For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. 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.

Section 2 – The Product Backlog

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 Owner is responsible for the Product Backlog, including its content, availability, and ordering.

A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, its Product Backlog also exists.

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.

The Product Backlog is often ordered by value, risk, priority, and necessity. Top-ordered Product Backlog items drive immediate development activities. The higher the order, the more a Product Backlog item has been considered, and the more consensus exists regarding it and its value.

Higher ordered Product Backlog items are clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are fine-grained, having been decomposed so that any one item can be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “ready” or “actionable” for selection in a Sprint Planning Meeting.

As a product is used and gains value, and the marketplace provides feedback, the Product Backlog becomes a larger and more exhaustive list. Requirements never stop changing, so a Product Backlog is a living artifact. Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog.

Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product. A Product Backlog attribute that groups items is then employed.

Product Backlog Refinement

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. However, they can be updated at any time by the Product Owner or at the Product Owner’s discretion.

Refinement is a part-time activity during a Sprint between the Product Owner and the Development Team. Often the Development Team has the domain knowledge to perform refinement itself. How and when refinement is done is decided by the Scrum Team. Refinement usually consumes no more than 10% of the capacity of the Development Team.

The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping understand and select trade-offs, but the people who will perform the work make the final estimate.

Section 3 – The Sprint

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, usable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.

Sprints contain and consist of the Sprint Planning Meeting, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective. During the Sprint:

• No changes are made that would affect the Sprint Goal;
• Development Team composition remains constant;
• Quality goals do not decrease; and,
• Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

Cancelling a Sprint

A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.

A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense.

When a Sprint is cancelled, any completed and “Done” Product Backlog Items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.

Sprint cancellations consume resources, since everyone has to regroup in another Sprint Planning Meeting to start another Sprint. Sprint cancellations are often traumatic to the Scrum Team, and are very uncommon.

Scrum Events That Involve the Product Owner

Sprint Planning Part One – What Will be Done This Sprint?

The Development Team works to forecast the functionality that will be developed during the Sprint. The Product Owner presents ordered Product Backlog items to the Development Team and the entire Scrum Team collaborates on understanding the work of the Sprint.

The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.

After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.

Sprint Planning Part Two – How Will the Chosen Work Get Done?

The Product Owner may be present during the second part of the Sprint Planning Meeting to clarify the selected Product Backlog items and to help make trade-offs but attendance is not mandatory. If the Development Team determines it has too much or too little work, it may renegotiate the Sprint Backlog items with the Product Owner.

By the end of the Sprint Planning Meeting, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.

Sprint Goal

The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint.

As the Development Team works, it keeps this goal in mind. In order to satisfy the Sprint Goal, it implements the functionality and technology. If the work turns out to be different than the Development Team expected, then they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.

Daily Scrum

The Product Owner does not need to attend the Daily Scrum but if they do, they should take no active part in it and simply observe. The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours.

Every day, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work together as a self-organizing team to accomplish the goal and create the anticipated Increment in the remainder of the Sprint.

Sprint Review

The Sprint Review includes the following elements:

• The Product Owner identifies what has been “Done” and what has not been “Done”;
• The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
• The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;
• The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date; and,
• The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning Meetings.

The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.

Other Scrum Matters of Interest to the Product Owner

Scrum Master Service to the Product Owner

The Scrum Master serves the Product Owner in several ways, including:

• Finding techniques for effective Product Backlog management;
• Clearly communicating vision, goals, and Product Backlog items to the Development Team;
• Teaching the Scrum Team to create clear and concise Product Backlog items;
• Understanding long-term product planning in an empirical environment;
• Understanding and practicing agility; and,
• Facilitating Scrum events as requested or needed.

Monitoring Progress Towards a Goal

At any point in time, the total work remaining to reach a goal can be summed. The Product Owner tracks this total work remaining at least for every Sprint Review. The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal. This information is made transparent to all stakeholders.

Various trend burndown, burnup and other projective practices have been used to forecast progress. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has happened may be used for forward-looking decision-making.

Increment

The Increment is the sum of all the Product Backlog items completed during a Sprint and all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s Definition of “Done.” It must be in usable condition regardless of whether the Product Owner decides to actually release it.

Development Teams deliver an Increment of product functionality every Sprint. This Increment is usable, so a Product Owner may choose to immediately release it. Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.

Summary

Almost every discussion on Scrum revolves around the Scrum Master with a passing nod to the Product Owner. But, neglect the role of Product Owner at your peril. They have a huge role to play in Scrum. In addition to all the work listed above, they protect the Development Team from distractions by external elements, enabling the team to concentrate on getting the work done. No doubt about it, that’s a good thing.