9 Tips for Creating a Good Sprint Backlog

24 March 2009

Luciano Felix
Especializa Treinamentos

The sprint backlog is a simple list of the tasks that must executed by the team in order to deliver an increment of functional software at the end of that sprint. Sprint backlog creation happens in the second part of the sprint planning meeting with the participation of every team member. Giving some real attention to this process is fundamental to a better understanding by the team about what should be done and to better planning during the sprint. Despite this, many teams still struggle with this activity. I hope these tips will help.

  1. Involve every team member in the process. It can’t be said enough: the involvement of every team member in the process of sprint backlog discovery is essential. On a multi-disciplinary team, everyone can contribute to task creation, enabling the team to draw from several different perspectives about the story. This generates a much richer Sprint Backlog than if only coders or a technical guru were involved.
  2. Discuss how every item should be implemented. Before any tasks are written on post-its it's necessary for the team to spend some time discussing every story that will be brought into the sprint. In fact, the majority of the meeting should be dedicated to understanding how the team is going to tackle the stories. This discussion will involve creating basic designs, checking existing code, discussing architectural possibilities, and so on. Having a shared understanding about the story and the possible solutions will enable the team to create a task list that truly expresses the work to be done.
  3. Have a definition of done. Having a common definition of done in place, available and visible to everyone is extremely important. This definition will serve as a guide to what should be done and will remind the team what the general acceptance criteria are for every item in the backlog.
  4. Identify all kinds of tasks. Too many teams focus on coding tasks. The truth is, though, that coding is not enough to deliver real working software. The sprint backlog should include every kind of task: object modeling, coding, learning a new technology, database activities, tests, and so on. Having a posted definition of done will help to remind teams of the tasks they are forgetting. By listing every aspect of delivering working software and going through those tasks, the team will gain a new understanding of the real effort the next sprint will require.
  5. Don't estimate tasks at all. This is a sensitive one. Estimating tasks in hours is popular and may be necessary when a team if first starting out. In the end, though, we can drop this without losing much. (See Alan Atlas’ article about this topic: http:www.scrumalliance.org/articles/116-a-cure-for-task-estimation-obsession.) The team commitment to the sprint should be done with the backlog items in mind, not the tasks. After all, if we estimate that a task will take 4 hours but it actually takes 12 hours, as long as the team achieves the sprint goal, what difference does it make? Identifying as many tasks as possible and creating a sense of constant progress during the sprint should be enough.
  6. Don't assign tasks up front. Resist the temptation to direct work; the team should decide who is going to do what according to the circumstances. If you start to assign tasks to the “most suitable” team member, it will prevent the rest of the team from learning new things, block communication, and decrease collaboration. Empower and trust the team to manage themselves.
  7. Review the sprint commitment. After task identification, when the team has a much better understanding about the real effort that is needed, the sprint commitment should be reanalyzed. Does the selected sprint backlog really fit in the sprint? If not, there are some alternatives. Drop the item with the lowest priority or split stories into smaller pieces. What matters in the end is that the team can commit to something they have a good understanding about.
  8. Don't use too much time. Respect the time box. Define a meeting duration and stick to it. Timeboxing forces the team to concentrate and intensively discuss the items, making it much more likely that the tasks will be uncovered. The team cannot always identify everything that should be done during the sprint, but that's not a problem. It is much more important for them to gain a thorough understanding of the stories they are bringing into the sprint.
  9. Evolve the Sprint Backlog during the sprint. The team will understand more about the stories as they work on them. New ideas may arise and old ideas may be dropped. The Sprint Backlog should reflect these changes. The Daily Scrum is an excellent time to create new tasks and lose unnecessary ones.

If the team invests the time and effort to build a good sprint backlog it will be rewarded with a much better overall understanding of the work to be done, a sense of progress on a daily basis, and a clear commitment to what will be delivered. It may not be easy, but it will be worth all the hard work.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 1 (1 ratings)

Comments

Girish Hegde, CSM, 3/31/2009 12:34:39 AM
I personally do not agree with point-5; Plus Alan AtlasΓÇÖ article never says do not estimate at all. At least till you realize your team's velocity you should be doing estimates.
But again, many times it becomes very hard to get a stable velocity due to team members quitting jobs, new resources joining the team, a team member could be good at doing something which is part of the current iteration, one of the team members could be a fresh graduate etc. In addition most of the organizations would be interested in metrics (eg. velocity in this case) to find out how good my team is in doing estimations or to compare the initial estimates as part of each sprint against the estimation done in the very beginning of the project using techniques like FP counting, COCOMO etc.
So I think in all such scenarios estimating tasks does make sense. As the project continues team will be able to do estimate lot faster and the time spent on estimating looks very minimal.
Peter Stevens, CST,CSP,CSM,CSPO,REP, 4/3/2009 12:22:20 PM
Actually I think point 5 could be a cool idea. What do you think of the following rule: "A task should be completable in one working day or less." That's a simple question to ask the team. If the answer is no, they have to split it up until each task is (or at least should be) doable in a day.

I'm looking forward to trying it out.

Cheers,
Peter

Juan Banda, CST,CSP,CSM,CSD,CSPO, 5/6/2009 8:11:22 AM
I do believe that having good estimates would be be very valuable, but at the same time we should not forget that Scrum is and adaptive and not a predictive technique.

Thousands of good and bad books have been written about how to make good estimations, reality is that there is no single, bullet proof technique that we can extrapolated from project to project and even from sprint to sprint.

What I'd recommend is that we don't loose time trying to have detailed estimations, agility principles recommend moving and getting things worked on the way.

For point 4 one very important thing is being stressed as it should: testing. Nowadays quality engineering work is a must in software commercial products. Consequently, sprint planning must take this tasks into consideration.
Lionel MOLAS, CSM, 7/1/2009 3:59:14 AM
If you do not estimate tasks, how do you plot you sprint burndown ?
Juan Banda, CST,CSP,CSM,CSD,CSPO, 7/10/2009 9:03:45 AM
I'm not saying that you shouldn't estimate tasks at all, that too me it's a little bit to extreme. What I'm saying is that not too much time should be wasted in trying to having detailed estimations, just have some gut feeling estimates in place and start moving.
Julie Hendry, CSP,CSM, 7/24/2009 4:32:21 AM
Re pt 9 - how can you prevent thrashing if the scope and solution are not agreed during sprint planning - IME this kind of freedom to change the solution within the sprint itself results in other stories not being delivered.
Julie Hendry, CSP,CSM, 7/24/2009 4:32:27 AM
Re pt 9 - how can you prevent thrashing if the scope and solution are not agreed during sprint planning - IME this kind of freedom to change the solution within the sprint itself results in other stories not being delivered.
Ram Sathia, CSM, 8/7/2009 4:16:12 PM
The tips mentioned in this article are very useful for creating a good sprint backlog. You have to be very careful while doing the task estimation. In one of our project we did estimation in points as well as in hours (independent). I found that 8 point task could mean 8 hours or 24 hours (variable range). I also found that when such type of task is under estimated or slipped, it could cost more. So whether you do point estimation or hour estimation, it is advisable to keep the task as smaller as possible (like 4 hour task). Slipping on a 4 hour task versus slipping on 8 hour task could mean a lot to meet the spring goal.
Mike Collins, CSM, 8/7/2009 4:30:04 PM
I agree that not estimating tasks is too extreme. The idea of making each task take one day sounds cool but in practice doesn't seem very desirable because you would have to artificially break down tasks to fit the time allocation instead of break them down naturally into discreet pieces of work. Also, most Scrum tools I have seen use task estimates to plot the sprint burndown charts. Are we going to do away with those too?

Yes, Scrum is adaptive but throwing out task estimation will lead us down a path to chaos. Of course no software estimate is perfect but my experience has been that a good Scrum team can do a much better job of estimating than old style waterfall techniques. A good scrum team also knows how much time to allocate to estimation because the sprint planning session is time boxed just like everything else.

You must Login or Signup to comment.