✄﹣﹣﹣﹣﹣﹣﹣﹣﹣
This article has been removed. An edited version appears in the book, The People’s Scrum, published by Dymaxicon, May 2013.
✄﹣﹣﹣﹣﹣﹣﹣﹣﹣
Read original comments…
A recent poster to scrumdevelopment writes “I find it challenging to get my team to articulate impediments [...] what types of questions do other scrummasters ask that help to get at these impediments?” [href="http://groups.yahoo.com/group/scrumdevelopment/message/39331"] [ref]
I don’t think it is about asking questions. I think it is about creating an environment of visibility and honesty. Task boards help us do that, but task boards alone won’t achieve it. Sometimes we need a whack to the side of the head.
The biggest impediment I have discovered to identifying impediments is the practice of measuring tasks in hours, and having team members update those hours at each meeting. People look at me askance when I make that suggestion. It doesn’t seem to make sense. But it does.
Some years ago, I took over as ScrumMaster for a team that had been doing Scrum “by the book” (their words). All of them hated the standup meetings, and especially the updating of hours. They felt they were being measured at a micro-level, that they should just be trusted to do the work and that it was insulting and a waste of time to be doing this. Well, being someone much more inclined to trust gut-feel than metrics I was happy to accommodate this request. The term “Scrumbut” didn’t exist back then.
We agreed that no hours would be put on tasks on the condition that all tasks were considered small enough to be completed in a single day. This is very important. What we discovered with this process change is that when tasks were not done in one day it was an indication of an impediment that no-one had thought to mention, or even acknowledged as an impediment. Now some of these impediments” are very tiny, such as “we thought the task was easier” so the solution is to break the task into smaller pieces, and commit to a smaller task for the next day, but other times it is indicative of a bigger problem.
For example, the team were falling behind, and one developer had a task sit in the in-progress column for three days. After one day he said it was almost done and just a bit bigger than he’d thought. We marked it with a red spot (this red-spot marking gives an immediate visual indication of the blocked tasks). After two days he said he didn’t have time to complete it. That raised some eyebrows. Why not? It turned out that this particular developer was frequently being called away to fix bugs in another property. This had nothing to do with the project he was on, and had not been discussed in the planning meeting. No one on the team had viewed this as an impediment because “that’s just the way we do things round here”. As ScrumMaster it became my job to change that.
This issue would not have come to the surface nearly so fast if we did not have the “one-day task” rule. The process of measuring things at a micro level, with the intent of creating visibility, actually serves to hide important information.
I recall another team I worked with (using an electronic tool to track) where the developers would knock hours off all the tasks they were working on, even if they knew they hadn’t done much work on them. They were all keen to see the burndown burn down, and didn’t feel safe saying the size of the task was the same or bigger. By the end of the sprint almost all tasks had about one hour remaining. Very few were done. No stories were done. This convinced me of the need for binary measurement. A task is either done or not done. A task with one hour remaining is not done.
Having this team stop measuring partially done work and measure only completed things (tasks and stories) helped them to create an environment of honesty and trust, and helped them to better understand what they could realistically commit to. It also allowed the impediments that were preventing them completing tasks to be surfaced much quicker (usually 24 hours)
Since 2005 I have discouraged all teams I work with to measure and track in hours. Using the “one-day task” rule will very quickly surface impediments and dysfunction. It will also free up your developers to actually focus on the work, and off the numbers.
Scrum requires a massive shift in thinking and behaving. Getting rid of the notion that measuring in hours is somehow necessary and helpful will be a great leap towards your Agile edge.
—
Related post: [href="http://agilethinking.net/blog/2007/05/21/estimation-time-or-size/"] [Estimation: Time or Size?]
click to subscribe
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.
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.
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.
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?
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.
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.
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.
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?
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.
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.
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
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