Work Stories, Not Tasks

Traditional or waterfall project management calls for definition of all tasks up front.  Each task has a “resource” (i.e. incorrect term for a person) assigned and an estimate for how long the task will take.  The task and the assignee are logical guesses that will likely come to pass, even if the task is less valuable when the person gets to it.  The time estimate is almost always fiction.  But these fictions feel like a foundation for a plan, so they are created and the assignee must follow them.  People have years of experience following this process of initially comfortable fiction.  When they are asked to follow Scrum, they sometimes have difficulty leaving the false security of a fictional plan.

One team I’m coaching had members with varying degrees of concern about estimating in story points.  The team had difficulty embracing story points instead of units of time because units of time matched their past experience.  We defined “ideal days” for estimation purposes.  An Ideal Day for our team was defined as 6 productive hours in an 8-hour workday.  The team would define a task for a specific team member who would estimate its work in ideal days.  They could determine how many features to include in a sprint by adding up the estimated ideal days against the length of the sprint.

This approach was pretty good:  The team was able to start using Scrum, plan sprints, use a task board and make serious progress.  Those are big benefits!

Some sprints later we began to notice some negative effects to this approach:

• We were still using time as the basis for estimates even though humans are better at relative size estimates.
• We were writing each tasks with a single, specific person in mind.  This contributed to a perpetuation of engineers going off in a corner to do “their piece” alone.
• To some extent, the tasks, and the availability of specific people to do them, were driving the order of the features implemented, instead of value driving the priorities.

Last retrospective the team pointed out that we were not meeting our goals.  We determined that part of this was the desire to make sure all the ideal days were booked with tasks for every team member.  This caused the focus of our tasks to be far too broad.  We noted many times where someone in the Daily Scrum would report an impediment because some other person had not completed their task.  The words “tracking dependencies” and “critical path” even came up!

In the time between the retrospective and the sprint planning meeting, I conferred with a colleague ScrumMaster about the retrospective.  He drew a one sprint long, mini Gantt chart (Gasp!) on the board showing the separate tasks for one hypothetical feature.   We could see that many times integration of individual’s pieces does not happen till late in the sprint, sometimes too late to expect it to work.  We realized that the focus on tasks was completely de-emphasizing delivery of the stories by the whole team.

Thirty minutes later we began the sprint planning meeting with the following proposed shift in the team’s work agreement:

• Don’t explicitly estimate individual tasks except when needed to clarify them further.
• Don’t explicitly assign a person to individual tasks.
• Do use stories that can be completed within the sprint.
• Do estimate the stories by difficulty, size, risk, etc. relative to each other using story points.
• Do have team members self-assign to each story so they will work together to get that story done.
• Do continue to work on the assigned story even if “your part” is done.
• Do support other stories in the sprint if you have time available.
• Do add or remove tasks as needed to get the story complete by the end of the sprint.
• Do track sprint progress on the burndown chart using the story points of completed stories.

We originally started this team by focusing on estimated tasks.  This got us going in the right direction but, after several sprints, helped push us into old ways.  Separate people waiting on each other is not a team.  Now we have a story focus with the understanding that the tasks are only important as long as the story gets done.

Work the story, not the tasks!  We’ll see how it works for us.  If the team board looks like this at the end of the sprint, it’ll be a success.

http://www.flickr.com/photos/dinomite/ / CC BY-SA 2.0

(I have been looking around the web while thinking and writing about this blog post.  Seems some teams and well known agile leaders don’t agree about estimating only tasks or only stories or both.  For example, Mike Cohn recommends story points for release and backlog planning but time on tasks for sprint planning.  Well, inspect and adapt is the agile way.  We tried only estimating time on tasks for a while and think we don’t like it.  This switch to story points may be what we need.  Or we’ll adapt again later.)