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.

I 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

Comments

[Davin Granroth]

Jack, thanks for this post! I'm a product owner at a company that has used scrum for about a year, and a lot of my work is to make smaller, more coherent user stories/product backlog items. It seems like the smaller a story gets, the less important it is identify every single task. At some point, the team knows what to do, so tasking it out helps us how? If we stuck to standard procedures in development, most of those tasks would simply be accounted for in how we work (this is how you deploy to production, run unit tests, yes you need a code review, etc).

Further on this point, I have a former business partner who does awesome IT work, but usually works solo. He's one of those rare gems that reiterates, models, plans, etc., and then executes really great code (he operates as a systems analyst/architect first, systems programmer 2nd). He's argued with me about scrum and TDD quite a bit saying that if he had to task all that stuff out first, it would increase the cost to substantive revision, which he thrives on.

This is to say, this approach you describe here might appeal a lot to his style of working.

[Jack Milunsky]

Right now I am sitting on the fence on this. I think both ways have merit and each one might be suited to specific situations, including organizational culture for example.

I do like the comment regarding tasking things up front may set you down a path that is not optimal as right at the beginning you know the least about how it's all going to work.

This is a good topic to dialog.

Jack

[Quooston]

I don't like tasking out up front because I feel that if a baseline architecture has been established, that everyone on the team understands what basic pieces are required to satisfy any story.

When we come to actually implementing the story, I have found that if there is work that can happen in parallel on that one story, we create tasks AT THE TIME, so that there is visibility in terms of who is doing what, and we aggresively monitor effort so that we don't overburn unknowingly.

[Joshua Partogi]

Hi Jack,
Thanks for writing this down. But I still don't get what's the whole point of estimating and writing the number of hours for the sprint burndown chart. If your estimation is wrong, you have to estimate the number of hours again on the following day, while if your burndown is based on tasks you don't have to re-estimate again on the next day.

[Dave Nicolette]

Sometimes I react too strongly to words, and this may be such a case. If so, then please ignore this.

To describe these differences as "two camps" strikes me as perhaps less than useful. It sounds as if people in each "camp" are dug into defensive positions and both sides have closed their minds and stopped practicing continuous improvement.

Rather than "camps," I think of these two approaches as different stages of maturity in the application of agile thinking. The lighter-weight your process can be without breaking down, the better. Some organizations can't support teams that dispense with story decomposition and task estimation. Some organizations could do so, but the technical teams aren't up to it. Context is important. IMHO the key thing is not to define rigid definitions of how to deliver software, and then fall into useless, circular debates about which technique conforms with which textbook. Once we do that, we are finished with this work, and it's time to move on to another career.

Cheers,
Dave

[Jack Milunsky]

Hi Joshua,

Eachy day is a brand new estimate of time remaining to complete the tasks. Based on the cone of uncertainty, your time remaining number should get more accurate the further into the project you are.

Appreciate your comments.
jack

[Jack Milunsky]

@dave. Awesome comments, thanks for sharing. I agree one has to keep an open mind and keep learning as you go.

I used the words camp as it's clear to me that their is this definite divide in the two methodologies based on opinions in the two communities. Never the less Scrum is a learn and adapt framework and so I would think that even the Scrum thought leaders wouldn't think that doing it the "XP way" is necessarily wrong.

[Chris Davies]

Interesting post. As a project manager, I am leaning towards Ron's school of thought on this. I prefer to track progress at the story level, since this represents more accurately what it is we are really supposed to be delivering - working features. It also enables extrapolation of the velocity to plan release dates.

My developers on the other hand, find it really difficult to estimate a story without breaking it down into tasks, even if it's just in their minds.
Another PM in our company takes the opposite view. He estimates everything at the task level in ideal hours. That his typical velocity (with 15 developers) is about 50 hours a day is indicative of the fact that they either cannot think of everything at the planning meeting, or the estimates are just poor.

Overall, I still like the idea of tracking at the story point level, and leaving decomposition into tasks until after the stories have been estimated, then leave them to have at it while I track story progress at the daily meetings.

Regards

[Jack Milunsky]

Thanks for sharing. It is a real interesting debate this one. And there is a definite divide in this regard.

I think the point that Ron made that I found most interesting is that he says breaking things down into tasks sort of implicitly forces you down that path, even though that path may not be optimum. But I still think it's a no brainer to just update your tasks as required if the plan changes and you figure out a better way to do things.

Cheers
Jack

[Alan Dayley]

Nice post!

This topic is an ongoing discussion. I think it never will be "finally decided" because what works for one team or company is not a good fit for all.

[Jack Milunsky]

Thanks Alan. I think I agree with you.

Jack