The scrum guide talks about sprint backlog items and other than explicitly calling out retrospective action items, doesn’t provide real clarity on what goes into it.
We advise teams to consider the following five types of work for the sprint backlog. While you may want to distinguish between more categories for statistical tracking, you will rarely want fewer than this.
- Stories
- Tasks
- Spikes
- Bugs
- Retrospective action items
Note that we’ve found that because electonic tools such as Jira often only have a “story” type that people get in the habit of referring to everything as a story, even when it has no business value. We encourage you to only use the word story when it really is one.
Stories
Stories are items of business value. Specifically, they have value to someone outside the team. That person doesn’t have to be a customer of the business - they could be an auditor or someone in production support or someone from a different part of the business. The point is that they’re not part of our team. We’re building something for someone who isn’t “us”. When we’re building things just for us then it’s a task.
Stories MUST be valuable and SHOULD be small.
When you have to make a trade-off decision between valuable and small, valuable must always win. If the item is reduced to work so small that it’s no longer valuable then it’s just a task.
The vast majority of items in your sprint backlog should be stories. These are the items that we’re building for others to deliver business value.
We call them stories because they’re part of a conversation, not a command. “Tie shoelaces” is a command. A story might be “Amy carefully tied her shoelaces so that she wouldn’t trip down the stairs again”. You’ll notice that the story was about someone who was doing something for some reason. What we often see in ticketing systems are commands: do this thing.
Tasks
Tasks are all those things that don’t fit in one of the other categories and the presence of these is a process smell. If you have any tasks then you’re likely making mistakes elsewhere and trying to compensate here.
Ask yourself why you’re taking time to work on something that doesn’t deliver value outside the team.
Spikes
A spike is a time-boxed experiment in order to make a (usually) technical decision. “Is it even possible to do this thing in a browser or do we need to do it on the server?”.
There are three criteria to a spike and each is here for a specific reason. If what you’re doing doesn’t satisfy all three, you aren’t doing a spike.
- A spike must be timeboxed and short. Less than half a day is normal.
- A spike must have a clear decision to be made.
- No code written within the bounds of a spike may be checked in. If you plan to keep any of this code, this isn’t a spike.
Bugs
Bugs are cases where things don’t work. See more details on bugs.
If there are outstanding bugs in the system then we should certainly spend the time cleaning them up.
Retrospective action items
These are action items, identified in a team retrospective, that the team has chosen to work on in this sprint. These are items designed to improve the team in some measurable way.
Every sprint should include at least one of these. If they don’t then we have to wonder if the team is actually improving. At the same time, there shouldn’t be many of them in any one sprint. While we always do need to be improving, these should not be our primary focus. Our main goal is delivering value and that’s found in the stories.