There's two camps - Tracking Stories or Tracking Stories and Tasks
I have been debating with Ron Jefferies on the XP User Group about whether or not it's useful to do task breakdown and track tasks on a burndown. This friendly debate demonstrates that people work differently under the Agile methodology. Differing perspectives and experiences are worth investigating. Hopefully my comments here reflect Ron's and the XP users' opinions accurately. A lot of what they say makes sense but it seems like each approach has merit.
Camp 1 - Scrum camp
Most teams practicing Scrum track sprints at the Task level but also use Stories and Story Points for planning. Stories are estimated Story Points. During Sprint planning, based on previous velocity (calculated from the number of story points that get completed in a given sprint), Stories are selected up to the maximum capacity of the team. Stories are then broken down into Tasks (in the second half of the planning meeting), Tasks are estimated in hours and tracked on the burndown. Each day a brand new estimate is provided for each of the tasks (mostly just the ones in progress). Hopefully the hours go down and your burndown burns down.
Camp 2 - XP camp
Most teams practicing XP track things at the Story level, thereby abstracting the minutiae at the task level. They generally like to work with small Stories - that brings some consistency to the process. Stories are placed on the board for all to see and move from open, to in-progress, to in-test, to complete. At the end of the Sprint, you just count the number of Stories and that's your velocity (i.e. number of stories per sprint). Or if you are estimating in Story points you just burndown Story points instead of hours. So next time around you know how many Stories on average you complete in a Sprint or Story points you complete. Obviously there's always discussion at the start and general agreement about how much can get done. It's not possible frankly to get stories to all be the same size. But on average if your stories are small, it all works out.
I personally like tasks as it forces the team to think about the implementation, assess complexity, risks, etc. At first I thought that Ron et al are against tasks. But that is not the case.
found Ron's comment very interesting;
"Considering tasks for a story is a good way of being sure we understand it and have its cost about right. Dividing up those tasks and doing them is not such a good idea."
My follow on question ...
"So breaking stories down into tasks is a good thing but then once you have the tasks - you do nothing with them?"
His answer (and this really sealed the deal for me)
"At the time we do this task breakdown, we know the absolute minimum
we will know about the right design at any time from now until we
complete the stories in question."
"To break up the work that way is therefore more likely to result in
a bad design, difficult integration, and defects."
"Therefore we should use the moment to consider the tasks, but
consider them to be ideas. Then we go ahead and build the
stories, with the design ideas in mind, but focused on the story
and building the best infrastructure we can, rather than the one we
imagined at the (worst possible moment) beginning."
I think what Ron's suggesting is very practical and makes a lot of sense.
I will make the following comment however. Many companies I work with would not be satisfied with this level of abstraction. I know most of the companies I deal with - their execs love the burndowns in hours. I know I do (although I am seriously considering trying the other approach now). Even if you do task breakdown in Scrum, it's not to say that you can't change the tasks as you figure out a better way of doing things. So I don't fully buy that building a plan around tasks is going to pigeon hole you into that design.
Love to hear your comments.
Written by Jack Milunksy - COO at Brightspark, certified ScrumMaster and Co-founder of Agilebuddy (Agile project management software that lets you easily Create, Estimate, Plan and Track your software development projects). For great Agile tips follow Jack at: www.twitter.com/agilebuddy. To get more info on Agilebuddy please visit: www.agilebuddy.com