Scrum Term Sprint Backlog
During my coaching sessions and workshops I got asked numerous times: What is a sprint backlog? Isn’t it just the top part of the product backlog?
Simply stated, within an agile development project, the Sprint Backlog is a document that lists the tasks to be performed as part of an individual iteration or sprint. During the Sprint Planning Meeting, the User Stories, which are approved, estimated, and committed, are taken up for discussion by the Scrum Team. Each Scrum Team member also uses Effort Estimated Task List to select the tasks they plan to work on in the Sprint, based on their skills and experience. The list of the tasks to be executed by the Scrum Team in the upcoming Sprint is called the Sprint Backlog.
The sprint backlog includes,
List of user stories within the sprint in order of priority.
Relative effort estimate for each user story.
Tasks necessary to develop each user story.
Effort, in hours, to complete each task.
At the task level, you estimate the number of hours each task will take to complete. Because a sprint has a specific length, and thus a set number of available working hours, you can use the time each task takes to determine whether the tasks will fit into your sprint. Once the Sprint Backlog is finalised and committed to by the Scrum Team, new user stories should not be added. If new requirements arise during a Sprint, they will be added to the overall prioritised Product Backlog and included in a future Sprint.
The scrum team collaborates to create and maintain the sprint backlog.
they are the people committing to completing the tasks,
they must be the people to choose what they are committing to, a product owner cannot force stories into a sprint.
The sprint backlog should reflect an up-to-the-day snapshot of the sprint’s progress. During the sprint, team members are expected to update the sprint backlog as new information is available, but minimally once per day. Many teams will do this during the daily scrum.
Tips for Creating a Good Sprint Backlog
Involve every team member in the process.
Discuss how every item should be implemented.
Have a definition of done. Having a common definition of done in place, available and visible to everyone is extremely important.
Identify all kinds of tasks.
Don’t assign tasks up front. Resist the temptation to direct work; the team should decide who is going to do what according to the circumstances.
Review the sprint commitment. After task identification, when the team has a much better understanding about the real effort that is needed, the sprint commitment should be reanalysed.
Don’t use too much time. Respect the time box. Define a meeting duration and stick to it.
Evolve the Sprint Backlog during the sprint. The team will understand more about the stories as they work on them. The Sprint Backlog should reflect these changes.
The sprint backlog can be maintained as a spreadsheet, but it is also possible to use your defect tracking system or any of a number of software products designed specifically for Scrum or agile, like JIRA. Another common practice is that it is represented on a Scrum board or task board, which provides a constantly visible depiction of the status of the User Stories in the backlog.
Attention Point: During a sprint, new tasks may be discovered and tasks already identified may be adjusted. This is perfectly normal behaviour. The Scrum team simply adds the new tasks (and an estimate of the work remaining on that task) to the sprint backlog or adjusts the wording (and if necessary the estimated work remaining) for tasks in progress.
The sprint backlog fulfils purposes of more than one project document and thus plays an important part in maintaining and transferring project information. If the team invests the time and effort to build a good backlog it will be rewarded with a much better overall understanding of the work to be done, a sense of progress on a daily basis, and a clear commitment to what will be delivered.
So what is now the main difference between the product and the sprint backlog?
The product backlog is a priority list of user requirements, use cases to be done in order to create, maintain and sustain a product. Product Owner owns the product backlog, (s)he is the one who prioritise it based on the customers feedback or business value.
Characteristic of a Product Backlog
It is a very active document where all the wish list and user requirements are gathered
Product owner makes sure that content of product backlog “user stories” are defined in detailed level
user story in product backlog should be enough in sizing to be fit in one sprint
All aspects like use case scenarios, condition of satisfaction aka acceptance criteria should be provided in each of the user stories
The product backlog acts as an input to the sprint backlog when comes to functionality
There are also bugs/issues, epic, user stories and themes are included in the product backlog
There are also bugs/issues, epic, user stories and themes are included in the product backlog
To put it short: The product backlog is the wish list for the product for the whole life cycle. It defined with its detail nature what to be implemented.
Techniques Used To Maintain Product Backlog Effectively
DIVE - technique for prioritisation
Product backlog items are prioritised in linearly ordered based upon;
DIVE criteria
Dependencies – keep it linear with fewer dependencies with other user stories, epic or themes. It’s OK to have horizontal dependencies.
Insure against risk (business and technical)
(Business) Value
Estimated Effort
DEEP - Technique for ordering user stories
The product backlog is usually ordered on the DEEP criteria
Detailed
Estimated
Emergent
Prioritised
INVEST - Technique to write proper user stories
User stories are usually written based on the INVEST criteria
Independent The user story should be self-contained, in a way that there is no inherent dependency on another user story.
Negotiable User stories, up until they are part of an iteration, can always be changed and rewritten.
Valuable, a user story must deliver value to the end user.
Estimable you must always be able to estimate the size of a user story. Small User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
Testable The user story or its related description must provide the necessary information to make test development possible.
What makes now a sprint backlog?
Sprint backlog is the subset of the product backlog. Each sprint, scrum team picks the user stories from product backlog on top of its stack, the number of user story picked by scrum team for a time box sprint is based on the average velocity of a scrum team. Product Owner set the sprint’s goal for the team, scrum team pick the user stories from product backlog fulfilling those goals. Those user stories which moved to sprint is owned by scrum team, as the team is committed with the sprint backlog items during a sprint which is in time box.
Characteristic of a Sprint Backlog
Sprint backlog is not dynamic in nature, each sprint the above scenario is repeated.
During each sprint planning session, the team returns back to product backlog to pick recently prioritised user stories for the sprint.
Sprint backlog is a subset of product backlog
Sprint backlog is an output of a sprint planning meeting.
In Sprint backlog, scrum team works on how the user stories would be implemented in a sprint by dividing it further into tasks and estimating it.
Assuming Product Backlog has stories: 1, 2, 3, 4, 5 and 6. The team decides to do stories 1, 2 and 4. As during sprint planning team realised that there still some question which is not answered well by the Product Owner, so they decided not to include the user story no: 3 and jump to user story no:4, which was defined well.
Sprint backlog is owned by the Development Team and contains what and how it gets delivered
Lastly in sprint backlog team implementing (converting) the most prioritised product backlog items into working software. For each iteration (sprint) the team creates a new plan, based on what is in the top of the Product backlog when starting the sprint.
I have found that the most important rule to keep the team efficient and effective is: “Shield the team from interference from the outside” So called “urgent requests” a deadly for an efficient Agile delivery team
