Creating The Sprint Backlog For Product Owners

The Scrum Sprint backlog is a list of tasks from the product backlog that the team has decided to be completed during the next sprint. The tasks and the order of their completion are decided by the Product Owner. The Product Owner is the voice of the customers, aimed at creating maximum value with each sprint.

In essence, the act of creating the sprint backlog is very straightforward. You take the product backlog where all the tasks are estimated and in a prioritized order, and you draw a line. All the tasks above the line go to the sprint backlog and are committed to being delivered during the next sprint. The rest of the tasks remain in the product backlog waiting for the next sprints.

In practice though, drawing the line / creating the sprint backlog is just one small step in a list of many things to do and consider.

This article goes over the aspects of creating the sprint backlog from the perspective of the product owner.

Creating the user stories

The Product Owner is the voice of the customer. The Product Owners daily job is to create user stories based on the input from users, customers, internal stakeholders and the product vision. These user stories then get complexity estimations from the developers and priority in the backlog based on the balance between the value created and the effort needed.

Backlog prioritization

Backlog prioritization (sometimes also referred to as backlog refinement or backlog management) is a Scrum ceremony owned by the Product Owner. The purpose of the meeting is to keep the product backlog estimated and in order – making sure that all stories are still relevant, estimated and ready for delivery by the team.

This is the truth hour for the product owner as it is where the prepared user stories meet the developers and get the feedback whether the tasks are ready for estimation and delivery or not. Usually (but not always) the whole team is present for prioritizing so that later the whole team can take the commitment to deliver the sprint (as they were present when the tasks were discussed and have all the information required).

The items on the top of the product backlog are gone through in more detail, making sure all information required is in the story and estimated using planning poker (e.g. complexity points like 1,3, 5, 8 and 13). Items further down are discussed more briefly and given rough t-shirt estimations (e.g. Small, Medium, Large) to give the product owner first indications on size. The planning poker estimations are crucial for planning a few next sprints. Rough t-shirt estimations help in further story development and prioritization. It can often be that based on initial t-shirt estimation, a task gets deprioritized in the backlog as the benefit is (currently) not worth the effort required or is so small that it can jump to the top of the list.

Ideally, by the end of a prioritizing session, all the tasks in the product backlog have an estimation, some estimations have been updated in light of new information and the backlog is prioritized. Depending on the teams’ history and the product, full estimation and prioritization of the whole backlog can be difficult to achieve. The important thing to remember is that a bit more than one sprint worth of stories for the team needs to have detailed story point estimations. This is because only estimated stories can be added to the sprint backlog during the Scrum planning meeting.

<– Continue Reading –>

Our Book Recommendations

We found these books great for finding out more information on Agile Scrum: