All About Agile | Agile Development Made Easy!
How to deal with incorrect estimates during a sprint?
What's the best practice when it comes to accounting for an incorrect estimate in respect to a burn down in a sprint?
Do you revise the estimate based on what you now know, or do you just increment the burn down at a slower rate to effectively drag it out longer?
Thanks.
Do you revise the estimate based on what you now know, or do you just increment the burn down at a slower rate to effectively drag it out longer?
Thanks.
Views: 83
Replies to This Discussion
-
Permalink Reply by Duncan Campbell on -
I presume you're referring to the situation where something is now estimated to require more effort rather than less.
Therefore, the estimates on the scrum/task board are updated, then the burndown chart shows an upward kink (or a less downward one).
The fact that estimates have gone up will be revealed in the daily scrum - if it's not revealed, then there's something wrong. This information can be taken into account by the product owner, scrum master and team:
drop lowest priority requirements,
reduce scope of requirement whose effort estimate has increased,
brainstorm to find a faster, more intelligent solution,
etc.
The burndown chart reflect the total remaining effort - this should always head downwards, but re-estimation because of discovered information means that it can head upwards, or it can head down at a slower rate.
The point is that this information is visible to all at an early stage, and all are free to act on that information.
-
Permalink Reply by Ilja Preuß on -
First and foremost, estimates are *always* incorrect - that's why they are *estimates*.
What exactly do you track on the burn down? Task hours? Story points? Something else?
-
Permalink Reply by Tariq Ahmed on -
Correct, estimates are estimates. So the question is, what's the best practice for revising them to a more accurate number during a sprint? Leave as is and alter the rate of burn, or adjust the initial estimate to what it should have been.
We're tracking tasks/user stories.
-
Permalink Reply by Ilja Preuß on
-
What would happen if you just left the estimate as is?
-
Permalink Reply by Radha Israni on -
you will look silly at the end of sprint when product owner/users find out that you had estimated finishing x points(and hence y features) but you could only manage x-1
if you sit in a corner with a bunch of developers creating an in-house web application - some facelift or some litter twitter , some share this or some feed that - probably not much will change - but if you do this in a client environment who pays you money to deliver some functionality and get famous for giving wrong estimates then you will likely have some career planning to do. (maybe the culprit could then become a full time blogger or twitterer)
-
Permalink Reply by Ilja Preuß on
-
As far as I can tell, reestimating tasks during a sprint doesn't impact how many features we will finish, does it?
So, how does reestimating tasks prevent you "looking silly"? And would it be possible to not "look silly" at the end of the sprint without changing the estimate of tasks during a sprint?
-
Permalink Reply by Tariq Ahmed on
-
Well my goal was to see what's the general practice in the agile community - and then just go with that.
If you estimate 24hrs to a task, and you burn it down at 8hrs a day... your burn down would show it's done after 3 days. But if you estimated incorrectly, you'd still be working on this. So if you don't do anything in terms of tracking, the team is still putting work into it, but it's not visible anywhere - the chart will show it's done, when it's not.
So, you either burn it down at a slower rate, re-estimate it so that you can accurately burn it down properly, or do nothing and I guess split the remaining work out as another task.
It sounds like re-estimating would be the best approach to track as to where things are.
-
Permalink Reply by Ilja Preuß on
-
I would actually advice against estimating in hours.
-
Permalink Reply by Tariq Ahmed on
-
Days is better? What if something is only 4hrs?
-
Permalink Reply by Ilja Preuß on
-
No, sorry for not being more clear.
The most common estimation practice I'm aware of is to use some kind of abstract points instead of units of time. Estimate Tasks in points relative to each other (and relative to tasks from earlier sprints). Measure how many task points you can do in a sprint.
I actually wouldn't count unfinished tasks as "burned down" in the chart. Yes, that means you should prefer to have rather small tasks. That's a good thing. -
-
Permalink Reply by Simon Kiteley on -
If I'm reading what you wrote correctly in the second paragraph. I don't think your burn down should reflect that just because you worked on something for 4hrs you knock 4hrs off.
For example if a task is 8hrs and you work on it for 4hrs. But only really done 25% of the task then your burn down needs to reflect 2hr rather than 4hr progress. This way the slope will flatten and you can see the trend is that things are going to be later.
That might sound a bit silly [knocking 2hrs off when you worked for 4hrs]... another reason to use some kind of point than hours!
Or like Ilja below suggests only count something as completed when its done but you need small(ish) tasks. Which would show the same thing but that does rely on you being mature enough you can define smaller tasks.
-
Permalink Reply by Phlip on -
I suspect this applies: http://www.agile-community.com/xn/detail/4633438:Comment:4151
© 2012 Created by Kelly Waters.
