A sprint planning meeting has two purposes:
- Agreeing a sprint goal
- Creating a sprint backlog
I have seen some teams where both these artefacts have been one and the same. The sprint goal is to complete a list of stories. The sprint backlog is that list of stories.
This is certainly one way to do it but not a good one.
I touched on what constitutes a good sprint goal in my previous blog post about preparing for the sprint planning meeting. Today, I will be looking a bit more at the sprint backlog.
There is more to a sprint backlog than user stories
The Scrum Guide describes defines the sprint backlog as “the Product Backlog items selected for this Sprint plus the plan for delivering them”.
What this means is typically a list of user stories together with the tasks needed to deliver them.
Stories are thin, vertical slices of functionality that include all the different types of work that make up working software, such as UX, development and testing. Often, stories will require the involvement of several team members with different skills.
Tasks, on the other hand, are the things the team need to do to deliver a story. Typically, a task should be possible to complete by one person (or a pair). Some examples could be “Create UX assets”, “Write feature files” or “Create database migration”.
Why breaking stories into tasks matters
Creating tasks for the sprint backlog will help us in several different ways:
- Understanding the work. The task breakdown itself helps the team make sure they understand the story and the work involved. If any requirements are unclear, this is likely to surface during the task breakdown if not before.
- Ensuring the sprint goal is realistic. If the team realise while doing the task breakdown that there is too much or too little work in the sprint, they can go back to the product owner and suggest alternative approaches or adjust the sprint goal as necessary.
- Making progress (or the lack thereof) visible to the team. Rather than a story sitting “in progress” for a week, tasks should be moving across the board daily. This allows the team to better see how their work is progressing and adjust their plan when problems arise.
- Enabling collaboration on stories. When the tasks making up each story are visible on the task board, it is much easier for team members to share the work. Rather than each person having “their own” story, people can easier see what they can do to help meet the goal. Stand-up updates move from being “Yesterday, I worked on this story and today I will do the same” to “Yesterday, I created the view so someone should be able to pick up the test automation. Today, I will be doing the CSS.”
How to break a story into tasks
What the tasks will be will obviously vary from story to story and it is hard to give any hard and fast rules. A good goal to aim for is for a task to be between 4 – 8 hours. Keep asking “what do we need to do to do that?” until the tasks are small enough.
That is, small enough but not too small. Trying to identify every single little task in the sprint planning is likely to be a waste of time. No matter how hard we try, we won’t think of everything we need to do. Better then, as Mike Cohn suggests, to aim to identify about two thirds of the tasks and make sure to set aside time in the sprint to deal with the additional things that come up.
We don’t have to break down every story in the sprint planning meeting
Some teams only break down the first few stories in the sprint planning and then do a mini-kickoff when getting close to running out of broken down stories during the sprint.
This can be a good way to prevent the sprint planning meeting flor getting too long. Another benefit is that it reduces the risk of forgetting the details between when a story was broken down and when it is brought into progress.
The downside is that it makes it a bit harder to judge which stories are likely to fit into the sprint. For the stories towards the bottom of the sprint backlog, that might not matter so much.
Estimate the tasks – or don’t
Some find estimating each task in hours useful. Adding up all the hours can be a good sanity check to see if the work fits into the sprint. If doing this, don’t assume a two-week sprint consists of ten eight-hour days. We can almost treat the hours as another velocity: “We test to get through 100 hours of work each sprint”.
A quicker alternative than estimating each task, particularly if tasks are roughly the same size, is to just count the number of tasks.
Whichever method we choose, we will still be able to create a sprint burn-down if we want to. It will show the number of hours remaining or the number of tasks remaining. No big deal.
It’s impossible to everything that will happen in a sprint
Even if a sprint is a short time, we will not be able to predict everything that will happen. Maybe, the production system will break so that we need to deal with that. People might get ill. Upper management might take the whole team out for a couple of hours through calling an all-hands meeting. Or things might just take longer than we thought they would.
Therefore, trying to optimise a sprint down to the last hour is likely to fail. Ironically, it will even make it less likely to meet the sprint goal.
Use simple tools to manage the sprint backlog
When each task takes half a day to a day for a person to complete, we will end up with a lot of tasks in each sprint. What’s the best way to manage them? This is down to personal preference. Just make sure it’s the team managing their own tasks rather than the PO or Scrum Master micromanaging the work in the sprint.
The important thing is that it should be easy for the team members to add, remove and change tasks during the sprint as they learn more. If the tool we choose makes that hard, it’s probably not the most suitable tool for the task(s)!