Sprint backlog
| Sprint backlog |
|---|
| See also |
Sprint backlog - in the SCRUM methodology, it is a set of tasks selected from the backlog of the product, which is implemented in a given sprint. It is determined before the start of the sprint, when planning it. In contrast to the product backlog, which usually consists of user stories, the sprint backlog contains a list of specific tasks to be performed by the development team during the sprint.
All tasks in the current sprint backlog should contain the following information:
a description of the given task, including information about the user's story from which it originates, estimated time of task completion, member of the team responsible for the task, the status of a given task.
Steps for creating a sprint Backlog
Sprint's backlog is the result of sprint planning, in which the development team, Product owner and Scrum master take part. It is created in the following steps:
1. Selection of user stories from the backlog of the product
The team determines which stories contained in the product backlog will be completed during the next sprint. The following issues are taken into account in the selection:
- the sprint goal that was set by the team at the beginning of the planning,
- the priorities of the stories - usually the team tries to implement the stories with the highest priority in the first place,
- speed of the team - at what pace the team members work, and so how much work they will be able to do during the sprint. Two estimation methods are possible here:
- based on the speed of completing tasks in the previous sprint,
- based on the availability of the team, and therefore information on how much time each team member will work in a given project.
2. Division into tasks
Every single story that has been selected for the sprint is divided into individual tasks to be performed. Tasks should have the following features:
- be possible to be carried out by one person,
- the time of completing one task should not exceed 8 hours,
- performing all tasks for a given story results in an automatic "closing" of the story,
- have real value for the project - the sprint backlog should only receive tasks that have a real impact on the project; so we do not add tasks related to, for example, recruitment or organizational meetings to the backlog.
Examples of task types to which a story can be divided:
- preparation of documentation,
- UI project,
- test planning,
- test automation,
- implementation,
- meeting with the product owner,
- buffer,
- preparation of test cases,
- code review,
- tests,
- improvement of errors.
3. Task estimation
For each task that was defined in the previous step, the team determines the predictable time of its execution in ideal hours, so how many hours will it take for one person to perform this task in ideal conditions. If a given task is estimated to be over 8 hours, then it should be considered whether it would be reasonable to split it into several smaller ones - especially if the estimated length of implementation is several times greater than 8 hours.
Tasks should be assessed jointly by the entire team, and not by its individual members, without agreement with the others.
An example of a tool that can be used to estimate tasks is planning poker.
Changes in the backlog during the sprint
The owner of the sprint backlog is the development team, and only he can make changes during the sprint.
Backlog presents information about the status of a given sprint, which is why it is constantly updated during the sprint - for example, information about who the given task was assigned to and the status of its implementation are added.
There are changes in the tasks themselves, so if the team decides that all the necessary tasks are not taken into account during the sprint planning, or that the tasks have been incorrectly formulated, then they can make the necessary changes to the sprint backlog, and then continue working according to the new arrangements.
It is also possible to edit the backlog consisting of removing unnecessary tasks, or changes related to the estimated labor intensity.
A particular example of a change introduced in the sprint backlog is changes in the sprint range itself, i.e. e.g. removing tasks or stories from it, if the team decides that it will not be able to perform them within a given sprint. Such changes should, however, be determined through negotiations with Product Owner.
References
- Beck, K., Beedle, M., Van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M.,... & Kern, J. (2001). The agile manifesto.
- Vlaanderen, K., Jansen, S., Brinkkemper, S., & Jaspers, E. (2011). The agile requirements refinery: Applying SCRUM principles to software product management. Information and software technology, 53(1), 58-70.
- Moe, N. B., Dingsøyr, T., & Dybå, T. (2010). A teamwork model for understanding an agile team: A case study of a Scrum project. Information and Software Technology, 52(5), 480-491.
