The product backlog consists of a prioritized list of work to be completed. At the beginning of a project, the Product Backlog Items (PBIs) are typically:
- Features to be added (User Story)
- Knowledge to be gained - time-boxed investigations to learn more about how best to approach an upcoming PBI (Spike)
As the project progresses, additional types of PBIs are introduced:
- Defects that should be fixed
- Technical rework
Technical rework is typically the result of cutting corners to complete an earlier PBI. Taking on technical debt is a legitimate part of Scrum, but it is critical that technical debt is tracked and addressed. Left unmanged, accumulated technical debt can introduce challenges that make completion of additional features painfully slow.
- Ceremonies — sprint planning, sprint reviews, retrospectives... basically, meetings. Typically these aren't part of the backlog, but you will track them as part of senior design.
Fully developed product backlog items should:
- Briefly state the work to be accomplished
- Focus on business value
- Describe work that can be completed in one sprint
- Have clearly understood acceptance criteria
- Often written as a user story (
As a [role], I want [goal/desire] so that [benefit])
- Assigned an effort in terms of "story points", not hours (in GitLab we use the "weight" field to record the story points)
- Have a priority describing its importance relative to other PBIs
Throughout each sprint the backlog should be actively groomed (PBIs added and refined). The backlog should contain a mix of fully developed PBIs and more preliminary PBIs. At the beginning of each sprint there should be enough fully developed PBIs to fill at least one and a half sprints.
During sprint planning, the team should decide which PBIs will be added to the next sprint and create a list of tasks under each PBI that enumerate the tasks required to complete the PBI. These tasks should have time estimates associated with them. As a general rule, tasks should range in duration from 2 to 5 hours in length. Each PBI brought into a sprint should be completely fleshed out prior to the start of the sprint. During the sprint you may find the need to add or re-estimate tasks. That's bound to happen, but hopefully your team will find it happening less and less as the year progresses.