That’s the old story: we suck at estimating. Our schedules tend to be wrong not only because there are unexpected issues but mostly because we underestimate effort needed to complete tasks. There’s one simple trick which allows improving quality of estimates. It’s simple. It’s reliable. It’s good. On the minus side you need some time to execute it.
Split your tasks to small chunks.
If a task lasts more than a couple of days it’s too big – split it. If it’s still too big – do it once again. Repeat. By the way that’s what agilists came with over years – initial size of user stories was intended to be a few weeks long, now it’s usually a few days at most.
Why it works?
• Smaller tasks are easier to process in our minds. As a result we understand better what we’re going to do. As a result we judge better what means are needed. As a result our estimates are better.
• Smaller tasks limit uncertainty. In smaller room there are fewer places to hide. The fewer places to hide the fewer unpredicted issues there are. The fewer unpredicted issues the more exact are estimates.
• Small tasks mean small estimates. A month-long task should be read as “pretty long but it’s hard to say exactly how long” task. Bigger numbers are just less precise. Splitting tasks ends up with smaller chunks of work. Small chunks of work end up with small-sized estimates. Small-sized estimates mean more precise estimates.
As a bonus, during task-splitting exercise, you get better understanding what should be done and you early catch some problems which otherwise would appear much later and would be more costly to fix.
And yes, the only thing you need is some time.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
11 comments… add one
Great post Pawel. When I am working with people anything more than a day, maybe two, is too long.
You’re right that it takes more time to do. However, the time spent up front in this task breakdown exercise is almost always made up for by hitting, or coming close to hitting, your schedules.
John
The cool thing is the splitting tasks to smaller ones doesn’t require any specific skill whatsoever. You just go a level, or a couple of levels, deeper with anlysis you anyway.
One particular trick can be used to verify it’s worth – do rough estimates with couple-of-weeks-long task granularity and then come with estimates broken down to small chunks. I bet the latter will be way more precise.
Our last BUFD project had no task over 12 hours (‘cept project level tasks, e.g. “Project Management”, “Issue Investigation”). Took us 5 man-months to come up with a schedule.
The big problem was that all the tasks we completely missed.
I think there’s no technique which would help to estimate better tasks which aren’t there. The problem wasn’t within estimation but within break-down excercise.
And I think if you had just several 60-day long tasks you would give you more crappy schedule anyway.
This peace of advice is something I was looking for few years before a friend simply told me that I can not estimate nothing and that key to success is to keep estimations small.
He demonstrate his point with this excellent example of
5 minute task estimation.
Vukoje,
Interesting, but it looks like overkill to me. Naming specific problems you’re going to face is more like clairvoyance than real estimation.
However the example is insightful in terms of raising awareness what we do wrong when estimating.
Idea of splitting stories works in our team quite well.
One thought about estimation… Initial estimate for story is done using Story Points. The idea behind is that the maximum size for story that fits into iteration is 8 SPs so if story has more than that it needs to be divided into substories in order to be taken into account during Iteration Planning. The one tricky thing here is that sometimes it’s very hard to split story into smaller pieces, as there are some dependencies and implementing only one piece does not bring any ROI for customer. Anyway, that’s true that smaller work is easier to estimate.
Tomek,
One question just out of curiosity: what’s your team velocity?
And the another one connected with the problem you’ve brought: what do you do with tasks/stories which don’t suit your sprint? If there’s something too big to fit in one piece and there isn’t any method to split it to separate wholes.
Do you roll out some code which isn’t completed from functional point of view?
Pawel,
The average velocity per person is 6-7 Story Points.
Question 1. We are trying to descope story by making some additional assumptions. Or we commit that this story will be implemented however it will not cover all functionality mentioned at beginning.
Question 2. Yes, we had a situation where the whole functionality had been splitted into 4 stories, and we hadn’t chance to present the progress of work to customer as only having all stories implemented makes sense from business perspective. What we agreed is that set of integration/functional tests would have been produced to each story (yeah, I know this is not the perfect way).
I agree with you on splitting bigs tasks to smaller ones enhances our estimates.
But I believe that bigger contributor to the problem is that we don’t plan for the symantics around the task: meetings, discussions, preparations, checking, and all that is NOT the buffer we should give for “possible” obstacles like TFS server going down, or Bug in 3rd party component, these are the real delays as I see it.
The task is not only the key stroking part.
Good point. Actually if we do simple analysis how much time you spend on activities non-related wit task you may and with something like 50% if you’re out of luck.
On the other hand it can differ much. At the moment I work with small team where impact of the issue is minimal. Meetings, except of these tightly connected with tasks (e.g. on design or architecture), are non-existent. Interruption rate is incredibly low. There’s no task switching. It’s hard to measure precisely but I’d say the team is very productive.
And I have to admit accuracy of estimates is pretty high too.