The output of Sprint Planning is the 2nd artifact of Scrum: the Sprint Backlog. The Sprint Backlog:
- Contains the items selected for work this sprint
- A plan to deliver the items selected
- The sprint goal
Many Scrum teams struggle with what a Spring Backlog should look like. Because Scrum is a framework, no template is provided. Scrum’s rules are silent on what the backlog looks like in detail. It is up to the Scrum team to decide. However, I find that a lot of people struggle with the idea of a sprint backlog.
Here’s an example of a possible Sprint Backlog style your team could use that meets the rules of Scrum while also giving your team transparency to measure progress toward the sprint goal.
How does this work?
- Kanban. There is a Kanban in the top left corner for the Scrum team to use as valuable items are worked and moved to Done.
- Work states. If you aren’t sure what a work state is, read my article on this site about Kanban Fundamentals. I did not use “analyze, design, build, code, test” because these things rarely happen in anything approaching a linear fashion. As a developer myself, I never wrote a bunch of code and tested it. I would write a single thing, compile, and test over and over. Instead, these things are being worked, being shown to the PO, ready for sprint review, and then done when parked for release – whatever that means in the context of the team.
- Sprint Goal. I prefer to make the sprint goal a card and place it under the items that cause it to be completed. Not everything in the sprint contributes to the Sprint Goal in a lot of contexts. Let’s work on accomplishing our goal first and be clear about what does that. Ideally, everything in the Sprint would be part of the hypothesis the PO has for this sprint.
- Exit Policies. A good Kanban has a definition of done for each state of work defining what must be true for the item to be considered pull-worthy by the next state. The exit policy for working is the DoD.
- WIP limits. I left them off, because the plan below the Kanban helps create them. If it doesn’t work, and things are not getting done, add WIP limits to the WIP section of the board or the individual columns (or both) as desired.
- Plan for Delivery. To the right of the Kanban sit the items selected for work and a little detail about what has to happen to build and test each one. Try to keep this data off the board. Filling your board with a ton of task and sub-task cards makes it difficult for a customer or stakeholder to use. Some teams are forced to use sub-task cards because the company tracks hours booked by hourly workers using that. I wish they wouldn’t do that. Notice the 2nd two items are not spec’d out. I did that on purpose. It’s OK to not plan every detail of the sprint during sprint planning. It’s not OK to just select items and go.
- Sprint Calendar. I’d like to see the team collaborate on work. Pairing is nice, sharing is good. A plan is who is going to do what by when. Putting each selected product backlog item on the calendar for delivery to the PO creates transparency. It is visible when things are planned to be done, it is visible that the PO will be reviewing things throughout the sprint and not at the very end five minutes before the review. It is visible if people are working together or just taking their individual items up a tree (anti-pattern for Scrum). It also helps the team see if they have bitten off more than they can chew.
- Story Points. Where are the story points? I don’t like story points or estimates of work going into Sprints. I believe teams can guess at complexity with their intuition without numbers and goofy estimation systems. Using the DoD and simply looking at the calendar, they can get an idea if they can get work done. If you properly refine the backlog, everything is a 1 anyway.
You can make your Sprint Backlog any way you want, as long as you are the developers on the team. As a Scrum Master, I might dictate a style for the Sprint Backlog to start, just to get everyone going and speed things along. Expecting a new team to invent a Sprint Backlog when you could just provide a template is waste. However, the Sprint Backlog is made by the developers, so after explaining and demonstrating, stand aside and guide while they build it themselves. Every Scrum Master has the goal of the team being able to do this easily without them.
