What is a Sprint Backlog and when is Sprint Backlog Created?

Sprint Backlog is a list of work items that are picked up by Scrum Team members in a sprint. As the name suggests, Sprint backlog is the list of all the tasks which are to be worked upon in a particular sprint. Sprint backlog is the subset of Product backlog. All the tasks are stored in the form of User stories in the Product backlog. In Product backlog, Product Owner prioritizes all the User stories and based on the Priority, the Scrum Team picks up the User Stories to be worked upon in the Sprint and puts them into Sprint backlog during the Sprint Planning.

 

Sprint  backlog is created during the Sprint Planning which happens at the beginning of new sprint. In Sprint Planning, the Scrum Team identifies the User Stories to be completed for that particular Sprint and then with the help of Product Owner understands the User Stories and puts them in the Sprint backlog. During Sprint Planning itself, the Scrum Team adds the required tasks (known at that time) to the Sprint backlog items. Scrum Team also estimates the efforts required to execute the Sprint backlog items during Sprint planning and notes the efforts either in terms of Story points or the hours to each Sprint backlog item.

 

The Sprint backlog is owned by the Scrum Team since it’s the Scrum Team who is going to work on the User Stories. The Sprint backlog is created in every Sprint as a ritual. Without the Sprint backlog, the Sprint cannot be started. The Scrum Team is self Organized in nature and hence it’s the team who picks up the User stories that are to be delivered at the end of the Sprint and puts in the Sprint backlog. After Sprint backlog is created, Team assigns each User story to themselves and then based upon their analysis, works upon them. Sprint backlog is something which ideally should be fixed or static. Unlike Product backlog, Sprint backlog contains only Prioritized items to be delivered.

 

 

Sprint backlog should be such that it contains all the information regarding the User stories so that any new member working on it should be clear with the requirements. For that, the Sprint backlog should be updated. Any new changes, development or discussion yielding to new information should be updated in the Sprint backlog. Having said, one must avoid updating it every now and then. Ideally, Sprint backlog should be updated at the most once a day. Also, during Sprint planning, if the team picks up more user stories and later realizes that Team cannot churn down those many, then team should inform Product with the help of Scrum Master and if Product Owner agrees, then should remove few tasks. Similarly, if team has picked up less User Stories during the Sprint Planning then, again after discussion with Product Owner and with Product Owner’s agreement, Team should add more stories to the Sprint backlog. But this should not be a practice to add or remove Sprint backlog items. But it is very  important to update Sprint backlog with any new information received. Otherwise, during development, those things will be missed out and as a result, that piece of functionality in a User story will be not thoroughly developed.

 

Daily Stand up meeting is kind of update meeting in which 3 things such as What have you done yesterday, What are you doing today and if you have any impediments are discussed in 15 minutes time. Here, work is referred to a Sprint backlog item. After the Team performs some action with a goal to complete the User story, the time spent by the team on that particular sprint backlog item is then calculated and then hours are logged in that particular Sprint backlog item. This update to the Sprint backlog is usually done in the daily stand up meeting. Based on the time logged by the Scrum Team in any particular Sprint backlog item, Scrum master determines the amount of work completed for the User stories. Based on this calculation, Burndown chart is prepared by Scrum Master and this graph is then shared to the Product Owner.

The Sprint Backlog contains all the list of tasks in the form of user stories which are selected from the Product Backlog based upon the priority set by the Product Owner during Sprint Planning. However, the Sprint Backlog usually contains many other items that are not listed in the Product Backlog, which are as follows:

 

Work items that have been off from the list of user stories picked by the Scrum Team for the current Sprint.

Estimations for individual work items in terms of story points or hours.

Modifications of the “definition of done” since it is linked to a particular User story or task

Changes made to User stories that are not in sync with the Sprint Goal and which need Product Owner to abort sprint early due to some circumstance.

User stories or work items added newly by the Scrum Team within the Sprint

 

Basically the Sprint Backlog is a plan and plot of the current sprint. Scrum doesn’t articulate how that’s captured.  The Product Owner understands from the business users what is their priorities and which all functionalities he require to be developed on priority and then and conveys that to the Scrum Team.  The team with the help of their Sprint Velocity or depending upon the capacity planning picks up tasks and puts them in the Sprint backlog of this Sprint. After Planning, the Development Team should evaluate the total efforts of all the tasks against each User story assigned to them to their capability and make a final decision of what the Scrum Team can anticipate to complete in that particular sprint.