Bad Smells of the Sprint Backlog

Feel free to add your own bad smells in the comments below.  This article is my own opinion, and is based on my knowledge and Scrum Coaching experiences.

Does your Scrum Team seem to lose focus in the current sprint? Do stories stay stalled  for several days?  Does your team have trouble finishing the amount of work it committed to?  Does your team want to get more productive and increase their velocity?  Does your Scrum board confuse you?

Some of these situations are indicators that your team is not maximing it’s productivity in the sprint.  Removing some of the bad smells from your Sprint Backlog(some teams just refer to their Sprint Backlog as “The Scrum Board” or “The Board”) can help with many of these issues.

I define a “bad smell” as any symptom in a process that possibly indicates a deeper problem.  It doesn’t always mean the bad smell is indicative of a true problem, but most times it is.  Everyone on the Scrum Team is responsible for results, so any team member can point out these bad smells.  However, the one person ultimately responsible for optimizing the use of the Scrum framework is the ScrumMaster.  If your ScrumMaster is not identifying these bad smells to the team (and following up to make sure the team resolves them of course), then your ScrumMaster is not doing a terribly good job in the ScrumMaster role.

Bad Smell:  Sprint Burndown is not used to analyze the Sprint Backlog

Not using and updating a sprint burndown chart is breaking one of the fundamental rules of Scrum.  Sometimes teams are able to judge progress by gut feel or by just looking at the board, but this is very rare.  A team can learn very interesting things by viewing their burndown(chiefly, are we on track to get to ‘DONE’ on everything this sprint?).  If you’re not using it, start!

Bad Smell:  Sprint Burndown is not kept up to date

This is almost as bad as not using a Sprint Burndown at all.  The Scrum Guide is very specific on this topic, the burndown must be updated daily.  If you’re not updating it daily, then your team is not optimizing their work, or said conversely, your team is operating at a sub-optimal level.  Assign someone (maybe the role rotates) to update it every day, preferrably before your team’s Daily Scrum.

Bad Smell: Tasks change status in Daily Scrum

If developers move their tasks to “Done” during the daily Scrum, then obviously the burndown chart is now out of date.  If many developers do this, then the problem is multiplied.  It’s ok to point to tasks and stories on the board, but try to get your team to make a habit to either a) ALWAYS update tasks as SOON as they are complete, or at least b) ALWAYS update tasks 30 minutes prior to the Daily Scrum (That way the burndown is updated with fresh data just in time for the Daily Scrum).

Bad Smell: Everyone on the team doesn’t have at least one task “In Progress”

There are several causes for this smell, so identify it as an obstacle and bring it up to the team to resolve.

Potential Cause: Tasks are not reflective of the work that’s actually being done.

Potential Solution: Re-write the tasks so that they more accurately reflect what is actually being done.

Potential Cause: Roles on the team are siloed.  (“I’m a tester, and early in the sprint, nothing is ready to test yet?”)

Potential Solution: Cross train team members.  In theory, every team member should be able to pick up and do ANY task on the board.  Some might take longer than others to finish it, but that’s ok.  If your team is not cross functional, then there is no excuse for anyone to be sitting on the sidelines.  Have that idle person ‘pair’ with someone else so they become more cross functional.  Other things testers can do while being so called ‘idle’:  Prepare test cases and test data for stories in progress, help the PO write acceptance tests for stories coming in the next sprint, automating tests that previously had been done manually, researching new test tools, or refactoring tests.   No matter what they choose to do, there ought to be  a task on the board that describes what they are doing.

Bad Smell: Tasks not estimated

The Scrum Guide is very clear here.  Tasks should be designed to be completed in a day or less.  Further, they should be estimated in some consistent unit so that the Sprint Burndown can accurately track progress.  Most teams use hours, and many teams assume a 5 or 6 hour work day, leaving the other 2 hours for other corporate responsibilities, bathroom breaks, etc.  This means no task should be longer than 6 hours.

Bad Smell: Tasks not recorded, especially defects/bugs found in the current sprint

If a bug is found and fixed all in the same day, then by all means, don’t record a task for it, just do it!  Otherwise, the bug should be confirmed by a developer, and that developer should put one or more tasks on the board that represent the amount of time to code the fix and test the fix.  All too often teams either track these bugs elsewhere or don’t track them at all, and this means the current sprint backlog is not being represented well.  If a bug will be resolved in a future sprint(should be VERY rare), then the bug needs to be added to the product backlog.

Bad Smell: Tasks stay “In Progress” for more than two days.

If your tasks are designed to be one day or less, than no task should stay “In Progress” for more than two days, unless that task is blocked.  If anyone on the team notices this happening, they should ask, “What is blocking this task?”

Bad Smell: Tasks that are estimated and/or designed to span longer than one day

As is discussed above, tasks should not be designed to last longer than one day of effort.  If a task will take longer than that, the team should break it up into sub-tasks.  If the tasks are designed to be longer than a day, there will be much more slippage, and your burndown will not reflect actual progress.

Bad Smell: Not properly accounting for meetings when creating the Sprint Backlog

Go ahead and make tasks for all of your meetings that you think will happen in a sprint, even the Scrum ceremonies like the Planning Meeting, Retro, Backlog grooming, etc.  Also task any design or other scheduled meetings the team might have in order to work on a story.  Tasking your Daily Scrum is probably going too far.  Record the amount of time that the team estimates for the meeting, multiplied by the number of team members attending.  Your goal is to accurately account for about 5-6 hours of effort per day for each developer.  Once your team accomplishes this, they can then begin to inspect and adapt their estimates moving forward.  If a whole bunch of time is unaccounted for on the sprint backlog, then it becomes very hard to inspect and adapt your task estimating.

Bad Smell: Product Backlog item shows no task movement for several days

This is the “forgotten story.”  This is a story that shows no progress for several days.  In rare cases, it may just mean that no one has had a chance to work on that story.  If the story has been started, but has shown no progress for several days, a team member should speak up and say “What’s blocking this story from getting to Done?”

Bad Smell: Ideal line is not used on the Sprint Burndown.

Using an “Ideal line” is not a required part of Scrum, as specified by the Scrum Guide.  However, I still consider it a bad smell to not be using one.  The ideal line should be the sum of capacities (5-6 hrs/day X number of developers X number of days in a sprint) for the entire team for the sprint.  If you must, you can adjust capacities of those who are matrixed in, but you should also know that the more matrixed in resources you have, the less productive your Scrum team will be.  So, the ideal line is drawn between the total capacity hours for the team for the sprint, beginning on Day One of the sprint, down to zero hours on the last day of the sprint.  This line will often tell us if we’re ahead of or behind schedule.  I use a rule of thumb that, for any team who has executed 3-4 sprints already, we automatically don’t care about the ideal vs. actual comparison unless they are more than 15-20% different.  Anything inside that band (below or above) is not in and of itself indicative of a problem.  If it is outside of that band, it’s an impediment that should be removed.

Bad Smell: Ideal line in Sprint Burndown is not used correctly to indicate team capacity.

I’ve seen teams start their ideal line on Day One of the sprint as the total number of hours remaining for all tasks in this sprint.  That is NOT an ideal line, because it does not reflect team capacity.  See Mike Cohn’s book (referenced below) for tips on how to draw a proper ideal line in your Sprint Burndown.

Bad Smell: Tasks way too detailed

Remember that tasks need not be terribly detailed.  They should be described in 2-4 words, and should generally be more generic than specific.  For instance, instead of “Add fields to jsp in PaymantPage.jsp”, something like “JSP changes” or “UI changes” is fine.  One benefit of keeping things a little more generic is you can use the same task description on different stories.  “UI changes” could end up being a task on most of your stories, and that’s ok.  Another benefit of keeping tasks more generic vs. narrow is that narrow tasks increase the chances of  work being missed in a story.  What if, in addition to adding those fields, you also needed to add validation for those fields in the UI?  As long as the team understands what the task entails, that’s what matters more than the text used to describe the task, so fewer words generally work better.

Bad Smell: A team member having more than 2-3 tasks “In Progress”

Cohn’s book has a good section on why working on more than 2 tasks generally degrades productivity.  Having 2-3 tasks in progress also prevents the burndown chart from properly measuring progress, much the same way that having tasks longer than about one day skews the burndown chart.  Many teams make a rule that a single developer cannot have more than 2 tasks in progress.  Another strategy is that, by definition, 3 or more tasks in progress by a single developer is an impediment that must be discussed after the daily standup so that the root cause is known and well understood.  Yet another strategy is to put one of the tasks back in the “TO DO” bucket, so long as it’s not a task on the critical path for the sprint.

Potential Cause:  Tasks poorly defined. Tasks are intertwined such that you can’t do one without the other without the other.  Combine tasks or redefine them so they can be done sequentially.

Potential Cause:  One or more of the tasks is currently blocked.  As long the impediments are well known, then this cause means the bad smell is not necessarily bad.  However, make sure the impediments are being discussed and removed!

Bad Smell: Not knowing who a task is assigned to.

It happens a lot.  People move the tasks but don’t indicate who is working on them.  Much of Scrum development is a team effort, and when a team member has to go around to each member and say “I need to discuss Task X, are you working on it?”, that creates waste and inefficiency.  Worse, someone starts the task and then forgets about it, but that would eventually  show up as one of the bad smells relating to a task staying “In Progress” for too long.

Bad Smell: Sprint Backlog not highly visible.

Highly visible does not mean an 8.5 X 11 sheet of paper or a web site.  Highly visible means something at least about 24″ X 24″, posted near the location of the Daily Scrum.  Hand draw it if you have to — most experts prefer that method anyway.  Don’t let the cool drawing features of Excel or some other Agile reporting tool seduce you.  It’s not worth your time unless it can be printed BIG!

Bad Smell: Double entry of Sprint Backlog into a tool.

If your team finds itself entering all of your Sprint Backlog tasks into a tool AND recording and tracking them on a board somewhere, you might want to stop and consider whether this is valuable or not.  For remote teams, it is sometimes valuable, but for most teams, chances are it is waste.  Tracking at the Story or Product Backlog level in a tool is often valuable, but tracking such minute tasks in both places (tool and board) is often wasted time and effort.

Bad Smell: Team working way out of line with priority.

This one is rare.  Once a team begins a sprint, technically there is no order to the stories.  It’s up to the team to optimize on which stories to work on.   However, when one of the high priority or critical path stories gets totally ignored for the first few days of the sprint, discuss it as a potential impediment.   Also in the beginning of a sprint, beware if folks immediately jump to the lowest priority stories.

Bad Smell:  Too many team members on a single story. (Overswarming)

I often hear new Scrum teams thinking they can all swarm on a single story.  Swarming is an advanced technique, and to do well, requires certain conditions to be true (highly cross functional team, non trivial story size, highly collocated team members, etc).  Don’t be smelly by just assuming your team can swarm on every story all of the time.  First, work diligently on setting the right conditions for swarming.  Then, try it it sparingly at first, starting with at least 2 team members per story, then working your way up to more team members.  Eventually you’ll bump into the “too many chefs in the kitchen” problem, but your team will learn the right balance over time and begin to do “smart swarming.”  Some people associate Swarming with attacking the highest priority stories first — I cover that concept under the bad smell titled “Team working way out of line with priority.”  See Mike Cohn’s blog entry for more info on Overswarming: http://blog.mountaingoatsoftware.com/should-a-team-swarm-on-to-one-backlog-item-at-a-time

Bad Smell: Team members dispersed across too many stories at one time. (Dispersing)

Dispersing is the opposite of Overswarming.  Team members march off into their silos and each work on a different story, never teaming up to get a story done.  This is a throwback to the old Command and Control days of software development, which means the strategy comes with much of the baggage of that kind of approach (bottlenecking, code dictatorship(“my code”), blamestorming, tribal knowledge, etc).  See the “Overswarming” bad smell for tips on how to grow your team into a place where they can do “smart swarming.”

Bad Smell: Story stays 90% done for several days.

The story that never closes.  It happens a lot with new teams.  Someone on the team needs to take to pick up the “closure football” and run that baby across the goal line.  The ScrumMaster(or any team member, of course) can help here by identifying the impediment and then asking someone if they will take the lead in getting closure.

If you need to combat some of these bad smells,  check out the relevant Sprint Planning chapters in Mike Cohn’s book, Agile Estimating and Planning .

May the Sprint be with you. 🙂

© 2010 Charles Bradley.  All Rights Reserved.

About the author:Mr Bradley is an experienced Scrum Coach, Certified ScrumMaster, and Certified Professional ScrumMaster I.  In addition to his Scrum credentials, Mr. Bradley is also a highly capable, full lifecycle experienced, software development team lead that prefers XP for good engineering practices.   He is Sun Certified in Java, and has  13 years of experience in J2EE application development across all tiers.  More recently he has also picked up some good C# experience as well.  In his spare time, he enjoys driving his wife crazy by talking about Scrum, especially when he refers to his “honey do” list as his “personal backlog” and asks his wife to prioritize her requests.  He lives in Denver, Colorado, and he is easily found on LinkedIn.