5 Ways to Boost the Management of your Product Backlog

A well-organized Product Backlog is crucial to the success of any Agile development team. According to the Scrum guide (version 2020), the Product Owner is responsible for managing the Product Backlog, but she may delegate the work (or parts of it) to others. And that is exactly what happens: often the items on the Product Backlog are created and worked out by several people in various roles. With that come some challenges. Because how does everybody involved know what to do? And how do you make sure everybody works on the right items of the backlog?

This blog describes five best practices for boost the management of your product backlog. These points should help you understand how applying a structured approach to Product Backlog management helps you get a grip on your software development process. It is targeted towards anybody involved in the preparation of Product Backlog Items, so the Product Owner, Business Analyst and the developers that take part in story refinement. It assumes you are familiar with the typical terminology used in agile development and particularly Scrum. When mentioning ‘user stories’, it refers to the concept introduced by Mike Cohn in his book ‘User Stories Applied’ from 2004.

1. Use a status flow for user story preparation

Scrum teams are used to having a status flow for structuring their development process. The exact statuses differ per team, but usually there are statuses to indicate that a work item moves from ‘Ready to be picked up’ to ‘Done’ through several steps, such as ‘In Review’ and ‘Testing’. This helps the development team keep track of the work in progress, distribute the work amongst the team members and adapt the plan if needed.

Similarly, the process to get a user story into the status ‘Ready to be picked’ up also benefits from a status flow. Preparing a user story involves several steps that need to be controlled by the Product Owner. By using a status flow for the refinement process, everyone involved is aligned on the activities needed to make sure that there is enough work prepared for the next sprint planning.

The statuses used for the refinement process differ per organisation, but the outline is always the same. You’ll need at least these statuses to indicate the relevant steps in the process:

• New: the user story has just been created and is still being prepared. Little effort has been invested in it yet. It contains the most relevant details such as the goal of the story, a brief outline of the intended functionality and a first draft of the acceptance criteria. A user story in ‘New’ may be up to 3 months of work and will often need to be broken down into multiple smaller user stories later on.
• In Refinement: the user story is being prepared for implementation. Initially, the number of people working on the story is limited. They will split user stories if needed, prepare the details on the functional changes and proposed technical solution.
• Ready for Estimation: the scope, the solution direction and the acceptance criteria of the user story are sufficiently clear and the story is ready to be discussed and estimated with the development team.
• Ready: the user story is fully refined and estimated and can be implemented.

Of course, the naming of these statuses may vary between organisations. Some call the ‘Ready’ status ‘Sprint Ready’ where others call it ‘Ready for Development’.

Many existing backlog tools, such as Atlassian Jira or Microsoft Azure DevOps allow the definition of custom statuses. This allows the Product Owner and the development team to easily see which user stories need to be refined or estimated.

2. Continuous Estimation

For a Product Owner (and many other stakeholders within an organisation), it is useful to always have a sense of the amount of work needed to complete a specific set of user stories on the backlog. There may be several reasons for this, depending on the type of organisation and product. Some examples:

• A company has a product with a release cycle of 3 months and needs to decide which features will be available for release by the end of the current cycle. This calls for an estimate of all user stories the development team will need to pick up in the coming 3 months.
• A company needs to have a business case for the development of a particular feature to decide if the benefits of development outweigh the costs. This requires a breakdown of the feature, and in an agile environment it makes sense to do the breakdown in user stories right away.
• A team is working on a particular feature, consisting of multiple sprints worth of user stories. Stakeholders within the organisation need to know when the feature is ready. This means that the Product Owner needs to have estimates of the amount of work represented by all user stories for the feature on the Product Backlog for the remaining sprints.

Of course, we want estimates on user stories to be as accurate as possible. However, that does not necessarily mean that only fully refined user stories may be estimated. In general, the more time is invested in the preparation of a user story, the more accurate the estimate is going to be (although not always, for instance if information is needed that is not available). But we do not always need the most accurate estimate on a user story.

When you do a sprint planning you want to have the most reliable estimate on all the stories in the sprint, because you want to plan a sprint that the team can actually complete. But when providing a prognosis for the total effort needed to complete 3 months of work, it does not make sense to fully work out the details of each user story. In this case all that is needed is a rough breakdown in a few more general stories, each with an estimate based on assumptions.

Rule of thumb

As a rule of thumb you’ll want an estimate on every user story in your backlog that may need implementation within the coming 3 months. As such even user stories in the statuses ‘New’ and ‘In Refinement’ need an estimate. And as the user story is worked out in more detail (and perhaps split into multiple user stories), the estimates are likely to change based on new insights by the people working on it. So, the estimate changes several times, up until the refinement is completed and the story is estimated by the whole development team and put in the status ‘Ready’.  Once in ‘Ready’ the estimate should no longer change and the story should be realised as soon as possible. If there is too much time between the end of the refinement and the start of the realisation by the development team, a user story may need to be refined and estimated again to allow new insights to be included.

Usually, the top of the Product Backlog contains user stories in various statuses. Because you want to be able to determine the sum of all estimates for a set of stories regardless of their status, it is best to use the same field and the same unit for all estimates. For instance, in Jira, use the ‘Story Points’ field for both the early rough estimates on new user stories and for those ready to be implemented. This allows using all built in reports and functionality of Jira for controlling the agile development process.

3. Find the rhythm

Agile development is all about rhythm. Scrum prescribes a clearly defined set of meetings once every sprint (or even daily, in case of the daily standup). Each of these meetings has a clear objective and follows a fixed structure. As a result, everybody present in the meetings knows how things are done and little or no energy is wasted on finding out what is the best way to do things. By doing things in the same way each time and on a fixed schedule we become familiar with them and we know what to expect from ourselves and from others. This frees time and energy for the work at hand.

Story refinement needs a rhythm just as well. You want to do a fixed set of activities for each story you refine so you do not have to spend too much time aligning with others on how to do things. And you want to have a sequence of repeating meetings planned once per week or sprint so that everybody knows there is an opportunity for discussions and asking questions sometime soon.

The goal of a refinement meeting

The most important meeting of the refinement process is the meeting in which the development team sits together to discuss the stories that are in refinement or ready to be estimated. This meeting is attended by all members of the team and the person(s) who prepared the user stories (usually an analyst or the Product Owner). The goal of the meeting is to make sure that everyone understands the objective of each of the stories and can judge the risks and challenges involved in implementing the stories. For each story discussed the most likely outcomes are:

1. The refinement of the story is completed. The story is estimated by the team and the story gets the status ‘Ready’.
   or
2. The refinement cannot be completed because there are some functional or technical questions that need sorting out first. Someone will have to do this before the next meeting, when the story will be discussed again.

Note that this refinement meeting is not one of the official events as defined in the Scrum Guide. But like any meeting in Scrum, this meeting is a time box. When the time reserved for the meeting is up (usually 1 hour each week) the meeting ends. Any user stories remaining will be discussed during the next planned meeting. And sometimes you may need to plan an additional meeting, for instance to make sure you have enough stories ready for the next sprint planning. On the other hand, if the top of the Product Backlog contains enough refined user stories to plan the next sprint (and some more), the meeting may take less time or can be skipped entirely.

What about the costs?

This refinement meeting is a potentially costly meeting. Depending on the size of the team there may be more than 10 people involved (including analysts and the Product Owner). So, it is important to keep the meeting effective. Someone (usually the scrum master or Product Owner) should chair the meeting and make sure that only user stories are discussed that are sufficiently prepared. Also, avoid making the meeting into a design session. If a discussion takes too long, assign some people to finish it outside the meeting and complete the refinement of the story in the next meeting.

4. Short User Stories

Size matters. That is true for almost anything and certainly for user stories. When the refinement of a story is done, it should ideally be no more work than one team member (theoretically) can complete within one week. Any larger and the story is too likely to be unfinished by the end of the sprint, simply because it becomes more difficult to oversee. So, when by the end of the refinement the development team estimates the size of a story to be more than a predefined upper limit, the story gets split into two or more stories which are estimated again. The upper limit depends on the team and may become higher as the team becomes more experienced.

Feedback loops

There are several reasons why you want stories that can actually be completed within a single sprint. First of all, agile development is all about feedback loops. By the end of every sprint the Product Owner needs completed user stories in order to be able to get feedback on the updated state of the product.  But agile development is also about predictability. A Product Owner needs the development team to be predictable in terms of the scope, quality and amount of work they deliver every sprint in order to allow the organisation to meet deadlines and commitments to customers and stakeholders. Apart from that, the development team deserves its successes. Completing stories motivates the team and keeps the work fun.

That does not mean that every user story on the backlog should be small from the get-go. User stories on the backlog that are in the status ‘New’ or ‘In Refinement’ can have any size. A higher estimate on these stories is an early warning that these stories are probably more complex and need more time to prepare. As the refinement process for these stories continues, they need to be broken down into smaller stories.

Splitting user stories

Can an user story always be split into smaller stories? Yes, they can. Although occasionally you might not end up with stories that make sense from a business perspective. But in the end taking multiple small steps gives you far more control than making one giant leap. So even though it might take some additional effort (like adding a feature switch to allow releasing a user story to production without exposing a partly completed feature) there is still a lot of value in having stories that do not add business value by themselves but focus on reducing risk or making technical preparations for a functional change. When faced with a story that you know is too complex to be completed in one sprint, the best thing to do is set some intermediate goals (i.e. separate user stories) and work towards them. You lose nothing (the intended functionality is still not completed within one sprint) but you gain control as well an opportunity to mitigate risks.

5. Refinement is teamwork

Just as realising a user story requires a collaborative effort of a whole team, preparing user stories is also a team effort. It takes specialists from various disciplines to add the relevant details on functionality, user experience, technology and quality assurance to all user stories in the Product Backlog. Within Scrum, the Product Owner is responsible for creating and communicating the items on the Product Backlog. In practice, the people tasked with the work of writing the user stories have job titles as Business Analyst, User Experience Designer, Architect or even Product Manager.

In some organisations they are organised in separate teams (often called Product Teams), while in other organisations these people are part of the development team that do the implementation. In all cases the development team is heavily involved in the refinement process, since they also contribute to the contents of the user story and eventually provide an estimate.

Keeping all these people aligned requires coordination, which is where the Product Owner comes in. The Product Owner’s main tool for controlling the refinement process is, of course, the Product Backlog. By changing the order of the user stories on this list, the Product Owner determines the order in which they need to be refined. Here the rough estimates in the unrefined stories help her setting the priorities and determining which user stories need to be worked out now, and which can wait until later.

Cost optimization

Refinement in a just-in-time process. To save time and money, the idea is to only work out the details that are needed right now. So, if a story will not be implemented anytime soon or may not be implemented at all, you’ll want to invest as little as possible in working it out. Only add the details you will need to decide if you will keep the story or not. As a Product Owner you will want to be able to decide not to implement a user story without any reluctance because of the time that has gone into its preparation.

In the end, it is the pace of the development team that drives the speed in which the refinement process takes place. Because it only makes sense to have enough user stories ready for implementation as the development team can realistically pick up in the next sprint (or two).

Get it done

Now take the next step. Add some statuses to your Product Backlog, plan a weekly refinement meeting, add rough estimates to and get into the rhythm. You will see that it helps you to get better organised sprints, less energy wasted in unproductive discussions and, most of all, more fun.