Unearthing Impediments by Doing Less

Posted on June 23, 2009 | 14 Comments

✄﹣﹣﹣﹣﹣﹣﹣﹣﹣
This article has been removed. An edited version appears in the book, The People’s Scrum, published by Dymaxicon, May 2013.
Update: this essay is now available as an except from the book, here.
✄﹣﹣﹣﹣﹣﹣﹣﹣﹣
Read original comments…

This entry was posted in Scrum and tagged Agile, Burndown, Coaching, Estimation, Scrum. Bookmark the permalink.

14 responses to “Unearthing Impediments by Doing Less”

Isaac Sacolick | June 23, 2009 at 3:56 am | Reply

Interesting post. I agree that measuring tasks by the hour does not reveal team impediments and like your “one day” task solution. However, measuring task/story applied hours does address other needs, for example, attributing an actual costs to features or validating estimates. Still, the breakdown doesn’t have to be at a granular level and there are ways to capture the metric without it being a burden on the team.

Response: Isaac, I agree with this. We can derive hours from story points in an empirical fashion, in order to understand cost of features and make predictions for release planning or to steer towards budgetary boundaries.
Jack Milunsky | June 23, 2009 at 3:58 am | Reply

Interesting post Tobias. So your teams don’t do a burndown then at all?

I must say, I personally love the burndown. I agree that one can be “bullied” into making the burndown look proper but hopefully this is not the case.

Got to try your suggestion sometime though.

Thanks
jack
blog.agilebuddy.com
twitter.com/agilebuddy

Response: Jack, I usually do a burndown in whole stories or story points. The story is the smallest unit of business value, so it makes more sense to me to track at that level. Some teams I work with like to do a task burndown too, for purely internal use, but they burn down on whole tasks, not hours.
Alan Dayley | June 23, 2009 at 4:20 am | Reply

This is great. Very insightful.

We have a team that has a difficult time breaking down tasks. Not surprisingly they also have a difficult time getting more than half of the burndown done by the end of the sprint. The “one-day task” rule should be great help for them to realistically define the tasks.

Response: Alan, I’d be interested in how this goes if you do use the technique. Please keep me in the loop. Cheers.
Mark Summers | June 23, 2009 at 8:52 am | Reply

Tobias thanks for writing this blog, this is an approach I have used with a number of teams since yourself and Boris Gloger described this approach on a CSM course back in 2006. The main reason this appealed to me was that on my first Scrum team having hours against tasks just brought out the wrong behavior, they would panic that they had only got 2 hours left on a task and they just couldn’t get their heads around the fact that management didn’t want them to cut corners to make the estimate. Taking hours out of the equation really helped, it removed any idea that people were going to be blamed for not completing their tasks fast enough. Management was never worried about tasks being complete in X hours, they wanted the valuable features, but in the old world that was how they controlled the team. Removing the notion of hours removed a big barrier between the Product Owner and the team.

Response: Hi Mark, how nice that you remember that. I think that may have been the first time I presented the idea publicly — in fact, I believe that was my first CSM training. Manchester, UK, right?
Siddharta | June 23, 2009 at 12:37 pm | Reply

Tobias, this sounds very much like a kanban type of process – dont estimate and use the flow of tasks to gauge progress. Would you say so?

Response: Hi Siddharta, I don’t know enough about what is being called Kanban these days to say. But in the process I describe there are certainly estimates. The stories are sized in relative points, and each task is estimated to take one day or less. I believe estimation to be a useful practice in any craft, as it allows for realistic predictions and healthy conversations with customers.
Richard Lawrence | June 23, 2009 at 3:57 pm | Reply

I’ve advised many of the teams I coach to do something similar:

* decompose tasks into less than one day (I suggest that they agree on 1 or 2 ideal hours as a target and always decompose to that level)
* only burn down on complete work (I like doing both task and story burndown and/or cumulative flow)
* flag when tasks sit in progress for more than a day (I change the daily Scrum questions to “What did you complete? etc.” to help make this visible and have also used the dots on the task board)

A nice side effect of using uniformly sized tasks has been much faster planning meetings. I’ve found that teams can decompose tasks to a small size much faster than they can estimate a set of tasks of various sizes, even when there are fewer tasks in the latter scenario.

Response: Good to hear this same method is working for you Richard, and thanks for the additional clarification. The side-effect you observe is very interesting.
Tom Reynolds | June 23, 2009 at 10:57 pm | Reply

Really liked this article and it is something that I’m trying to do but for different reasons, I had never thought of it before as an early site of an impediment.

My team break tasks down but we use quarter day increments as opposed to hours and I’m working hard with the team to make sure tasks are no more than 1 day, not there yet but not far off.

The reason for the one day tasks was that it is easier for people to handle and its units of work that fit in nicely with the daily scrum and therefore you should be onto a new task each day. This of course doesn’t always happen and we ask at scrum what the issue is. Obviously there are differing answers some of which I may have classed as impediments and others as not but I hadn’t ever really thought of them all as being impediments but of course they are.

We do still burndown on hours (a factor of a tool I use to generate the burndown) but having read this I like the thought of also producing a completed story burndown as it is of course stories we are ultimately interested in. I also like the idea of flagging the tasks.

This gives me some great things to think about and I’m sure I will change a few things around.

Thanks to all for this insight.
abby, the hacker chick blog | June 23, 2009 at 11:03 pm | Reply

great post, and good insight.

You’re reminding that when I first heard the notion of breaking my tasks down into things I could do within a day (McConnell’s Software Project Survival Guide in the late 90’s) I thought WOAH, micromanagement!! and wanted nothing to do with it.

But now, I’m on a very self-organizing team and I pick my work and I really enjoy having the smaller (within 1 day) tasks because at the end of the day I can always look back and know I accomplished at least one thing.

Maybe it’s a matter of perspective (manager handing out vs. self-selection of tasks), but I think you might be onto something with the # of hours. I’m terrible at knowing how many hours something will take and so it’s stressful if I try to hold myself to that. But I’ve gotten pretty good at “yeah, I can fit that within a day” and it feels good rather than oppressive.

And, you are so right about it getting right to the impediments! Now, if I just had a manager who would remove them all as you do, wanna come join my team? 🙂
Sean Hart | June 26, 2009 at 9:19 pm | Reply

I also strongly oppose the use of hour estimates on tasks and stories. An attempt to estimate a task to the hour is almost always met with failure (I say “almost” because you do get lucky sometimes and guess right). All this does is promote a culture of dishonestly. After awhile you’re spending more time and energy trying to maintain the illusion of the accuracy of your estimates than you are in getting work done.
Inanc Gumus | July 1, 2009 at 5:03 am | Reply

I agree. Working w/hour estimated tasks is a pain. It is time-consuming and not friendly at all. We are tracking our iteration w/story-count burndowns for 2 sprints. And it was very effective. We completed all of the stories, and had a feeling of ‘we’r completing and incrementing something’. I am recommending this technique.
Gerry Kirk | July 7, 2009 at 3:35 pm | Reply

I’m going to try this with a team I am coaching right now. One question tho – if no estimate on tasks, how do you do commitment-based sprint planning? Normally I’d have teams break stories into tasks, tasks into hours, deduct hours from available capacity.

Response: Have the team commit by “gut feel”. It is a much better indicator than any numerical data can offer you. Trust people’s experience.
Pingback: Penultimate | Agile Anarchy
davy.bold | December 15, 2010 at 11:00 am | Reply

One reason we have tasks estimated in (ideal) hours is to get a feeling after the breakdown, if what we plan to do works out with our (ideal) capacity. Otherwise I am all with this post on not using hours but creating tasks smaller than a day.

So, how do you guys get a feel for if your committment is doable then? Only by the story points and prior velocity or rather by gut feeling?
Pingback: Beyond Estimation | Agile Anarchy