Scrum is a popular agile framework for developing complex products that is usually a right choice for IT projects. In this inherently changing environment Scrum theory and values - if properly applied – can yield many benefits and ensure that value is delivered to customers and end-users at sustainable pace. Scrum is a viable choice and replacement for classic methodologies based on up front planning. It may also be an alternative to a mixed bag of agile practices employed by teams – Scrum can wrap around them and provide a better foundation.  

In this article I would like to share my knowledge and experience about two accountabilities (roles) within the Scrum Team – the Product Owner and the Scrum Master. I will focus on Scrum Masters service to Product Owners regarding Product Backlog management. I’ll describe what does it involve and why it is an important factor in a successful product development. 

Scrum Theory and Values

Let’s begin with a quick recap on Scrum as defined in the Scrum Guide (a definition of Scrum written and maintained by its authors). 

Scrum is a lightweight but complete framework based on empiricism and lean thinking. It is not a prescribed process but rather a set of simple rules that those using it must follow in its entirety to achieve desired goals. Scrum theory says that in complex environments we can only learn from experience and make decisions based on what was observed. Scrum keeps waste to minimum by employing iterative, incremental approach that avoids unwanted work and optimises value delivered to customers. Three pillars of empiricism – transparency, inspection, and adaptation – come together in Scrum and help the Scrum Team maximising the value of its work. 

For the Scrum Team to be successful it needs to become proficient in living five values: Commitment, Focus, Openness, Respect and Courage. This creates the best environment for Scrum framework to thrive and build trust among people using it. 

Scrum Accountabilities 

Scrum defines 3 accountabilities within the Scrum Team: the Developers, the Product Owner and the Scrum Master. 

The Developers are committed to creating value by turning Product Backlog Items into usable Increment of a product each Sprint. This can be for example, delivering a new feature or improvement to the working iteration of the product within a timeboxed event of a consistent length – a Sprint. 

The Product Owner is accountable for guiding the Developers so that the value of their work is maximised. It is one person respected and empowered by the organisation to make all important decisions about the product being developed. The Product Owner is also in charge of Product Backlog management – a central place of all things that describe how the product can be improved. The Product Owner can delegate this work to others but remains accountable. 

The Scrum Master is the last and the only role required to implement Scrum. It is not a traditional project manager as the Developers are self-managing. Instead, the Scrum Master manages proper use of Scrum as defined in the Scrum Guide. He is accountable for effectiveness of the Scrum Team that can be achieved in multiple ways including coaching team members in self-management and cross-functionality or causing removal of impediments to the Scrum Team’s progress. The Scrum Master works with the Scrum Team as well as a wider organisation in adopting Scrum and agile practices. 

The Scrum Master also serves the Product Owner. This is where I would like to elaborate more on Product Backlog management in this context. More in-depth description of Scrum, its events, artifact and supporting practices can be found in the Scrum Guide, related books and blogs. References can be found at the end of the article. 

Product Backlog Management – Make It DEEP 

Management of the Product Backlog is a very important process that helps maximising the value delivered by the Scrum Team. This is achieved by continuous prioritisation and refinement of Product Backlog Items (PBIs), so the Developers can always work on the most relevant items. A Product Backlog that is properly structured and organised also aids product and release planning (longer-term planning). 

A good Product Backlog can be defined as one adhering to DEEP attributes: Detailed appropriately, Estimated, Emergent, and Prioritised. I am describing these characteristics below along with the Scrum Master’s role and support for this way of shaping the Product Backlog. 

Appropriately Detailed Product Backlog 

We can say that a Product Backlog is detailed appropriately when it has just enough details. It means the Scrum Team has all the necessary information to perform near-term Sprints but at the same time PBIs that will be implemented later have less details. This prevents waste of spending time on refining items that are subject to change based on learnings from development. Different techniques can be employed by the Product Owner to control the structure of the Product Backlog but most commonly small and very detailed PBIs are moved to the top of the backlog to indicate priority and eligibility for picking up in one of next Sprints. Bigger, less detailed items would stay lower in the Product Backlog. The Scrum Master would typically recommend using some sort of a task tracker (e.g., Jira, Azure DevOps, Trello) to conveniently store, update and present PBIs along with encouraging and training the Scrum team in effective use of such a tool. Another advice could be to split PBIs into several categories that would highlight the size of an item (features, epics, stories) or it’s function (defects, spikes, technical improvements). Having diverse and self-explanatory PBI types can help with product planning and establishing a sustainable development cycle with technical debt and quality under control. 

Estimated Product Backlog 

A healthy Product Backlog is also Estimated. Initial investment in keeping PBIs reasonably detailed provides a good starting point for this activity. Not all the PBIs could be sized, or the same unit of measure used. More coarse-grained items are usually hard to estimate using numeric values and a T-shirt size method might be a good choice in such cases. Small, ready to implement stories though are good candidates for putting a number on them. With advice from the Scrum Master, the Developers should select a method of estimation that is intuitive for them, reasonably accurate and corresponds to the effort required to deliver an estimated PBI. Only the Developers are accountable for estimating PBIs, so the Scrum Master needs to ensure they are not influenced by the Product Owner or stakeholders and the process is a collective work of the team. To help with the latter the Scrum Master can propose additional techniques like Planning Poker and using relative units (story points, ideal days) to limit human deficiencies and reach team consensus on sizing. At the same time, he needs to observe and coach the team to avoid waste by being overly precise with the sizing (modified Fibonacci sequence as a scale can be a way to go). A sufficiently estimated Product Backlog helps the Product Owner in prioritisation. They would always prefer low-size (and thus low-risk) PBIs with high value over those with a similar value but bigger size. By frequently estimating PBIs, the Developers increase predictability of their work and improve accuracy of their estimates. Most importantly though, they learn how to discuss new functionality until their common understanding ends up in a consensus concluded by a measurable estimate. 

Emergent Product Backlog 

An Emergent Product Backlog means it’s not a fixed or baselined artefact, but it evolves depending on what is discovered from the customers, end-users or from the product development process itself. It supports empirical control theory of Scrum – the Product Backlog is a transparent entity, which is constantly adapted to current product’s environment by frequent inspection of Increments delivered every Sprint. The Scrum Team should take every opportunity to adapt, and the Scrum Master can help, facilitating that and coaching the team when necessary. This includes helping the Product Owner in making sure valuable feedback is reflected and highly visible in the Product Backlog whether it comes from Sprint Reviews, refinement activities or other meetings with stakeholders, customers, or users. 

Prioritised Product Backlog 

Finally, the Product Backlog should be Prioritised but only to a certain extent that is reasonable and required to sustain a steady inflow of features for Sprint and release planning. In practice, the Product Owner would not spend too much or any time on prioritising bigger and less detailed PBIs as they are too vague and risky for short to medium-term planning. However, they are still valid items that would stay at the bottom of the Product Backlog and express Product Goal or a wider product vision. The Scrum Master should always observe and be available to propose and facilitate any additional prioritisation activities with the Scrum Team or stakeholders if there is a danger of breaking the flow of features required for the development of near-term Sprints or releases. A good practice would be to dedicate some time in the Sprint Review to update priorities in the Product Backlog in relation to newly delivered Increment and changed business environment. 

Product Backlog Refinement 

A well-defined Product Backlog that is DEEP can only be achieved by the collective and continuous effort of the whole Scrum Team with support of internal and external stakeholders. Therefore, it is paramount to organise the Product Backlog management in a form of a refinement ceremony. The Scrum Master could suggest and facilitate a regular Product Backlog Refinement meeting for the Scrum Team taking place every Sprint, ideally in the middle of it. This reduces complexity of the process by letting the Developers prepare to the meeting, book it in their calendars, master PBI refinement techniques and allows them to account for refinement ceremony in team’s capacity forecasts. Regular refinement sessions could also help getting important stakeholders involved – they most likely would not be available ad-hoc. 

A model refinement session includes the Scrum Team and stakeholders such as business executives, subject matter experts, customers or even end-users. The Product Owner leads the session and invite participant external to the Scrum Team as needed to ensure enough input for the discussion. During the meeting, the joint team performs all the activities necessary to make the Product Backlog DEEP. They split bigger items and update them with more details as well as add new PBIs based on current business conditions, metrics, or user feedback. The Developers estimate selected items and the Product Owner prioritise them for a near-term Sprint based on new information. The Scrum Master can propose and organise additional workshops, especially prior to the project start or when ongoing product development is in danger of breaking a steady flow of ready to implement PBIs.  

Definition of Ready 

A consequent Product Backlog refinement can lead to a partial formalisation of this process. The Scrum Team may decide to create a checklist that contains the criteria that make a PBI “ready” thus eligible for the Sprint Planning. This useful technique not only saves time but also ensures that the team can build an inventory of PBIs that they can confidently deliver during one Sprint. A definition of ready may contain the following criteria to verify against a PBI: 

Like Scrum’s mandatory Definition of Done, the definition of ready defines a state of a PBI at a certain time in the development cycle. For the latter it’s the state at the beginning of the Sprint and for the former – its end. Highly effective Scrum Teams would most likely extend both definitions over time (including for example criteria related to non-functional requirements). The Scrum Master coaches the team in becoming more effective by taking opportunity to adapt during Product Backlog refinement activities. This can be strengthened by facilitating productive Sprint Retrospectives – another accountability of the Scrum Master. 

Closing 

The Product Owner and the Scrum Master should often collaborate to ensure effectiveness of the Product Backlog management activities as this process makes the work of the Scrum Team more valuable. The Product Owner remains accountable but should be proactively supported by the Scrum Master in finding appropriate techniques for the Product Backlog management, extending his service when requested or appropriate. Product Owners should always remember that they are not left alone and use collective knowledge and experience of the Scrum Team to solve difficult product discovery issues on the brink of business and technology. 

This article is by no means exhaustive in terms of how the Scrum Master can help fellow Product Owners in Product Backlog management. There are also many other areas where these individuals cooperate often and rely on each other. Stay tuned for my SoftwareHut blog updates! 

In the meantime, I highly recommend the following sources to learn more about Scrum and agile practices supporting it: 

Feel free to email me if you find this article useful or have any feedback. I’ll make sure to inspect and adapt 😊Thanks!