How to Create Your Product Backlog

The product backlog is always based on the roadmap. The backlog contains requirements that are sufficiently detailed and traceable. The requirements must be prioritized so that the most important requirements are at the top of the product backlog.

Each requirement must be estimated so that it is clear how big, difficult, extensive requirement is. For each requirement, the operator must determine the benefit (or value to the customer) listed. If the business benefits are vague or difficult to formulate, it will be hard to test the requirements.

Features of a good product backlog:

• There is a single backlog
• Known to all members
• Understood by all team members
• Easily accessible by everyone
• Live and continuously updated

The top requirements are ready for the sprint. They are detailed and estimates and value. Further down the backlog are requirements that are described in greater detail. There can be very detailed epics as well. When the requirements are transferred into sprint, is detailed and they are broken down into requirements that are ready for the sprint.

Regardless of the number of teams, there will be only one product backlog.

It is the product owner who owns Backlog and ensures that it reflects the vision. The Product Owner determines business benefits. The work of the backlog is ongoing. The product owner needs to continually evaluate the needs. This places great demands on the ability to switch between now and then. The product owner need to take the help of the team.

Backlog Refinement

Scrum does not give any guidance on how to refine your product backlog, so here is what we propose:

Agenda for refinement meeting

• New requirements
• Changing priorities
• Ready for the next sprint
• The impact on the upcoming sprint
• Estimates

It may also be important to include other topics in the agenda at different times. For example: bugs, regulations, new directives, changes in technology, the size (estimation) of a requirement or epic.

It is not always easy to prioritize requirements. How would you choose among these requirements? One requirement saves money over time, for example, a usability improvement that leads to lower costs for the help desk. The second requirement is a legal requirement that lead to sanctions if the change is not implemented to a certain date.

If you determine that you have time for both amendments might choose to start with the cost-saving measure, even if the savings are lower than the penalties that you will get if the legal requirement is not met. If you do not have time for both, choose the one that benefits you most or whatever loses the least.