For example, if I break a project into n discrete work products (say classes or functions or components) is there a time t such that n*t is a suitable amount of time to spend on estimation?
3
-
10It's easy. Just plan some time to look at your work load and estimate approximately how long the estimates will take and...oh, wait.– joshin4coloursOct 3, 2012 at 16:56
-
Since your estimates will all be wrong all the time, zero return on investment = zero time spent. Oh except bosses will force you to create bogus estimates. Agile estimates where you pick some random fibonacci number in some random unitless unit of measure called BogoEstimons, or something, seem better than estimates in real human hour work units.– Warren POct 3, 2012 at 23:24
-
Estimate time for estimating task. Let the Estimateception begin– userOct 4, 2012 at 4:08
Add a comment
|
7 Answers
If you have enough information to have broken it down to that level, you shouldn't spend more than a minute on each one. You're not going to be correct anyway, but you're going to be as correct after a minute as after an hour.
If, on the other hand, you were talking about user stories, I would suggest getting the stakeholders in a room and spending five minutes asking questions before estimating.
Regardless, don't waste much time doing estimates. They're not useful or accurate enough to be worth the effort.
-
3+1. but I don't agree that estimates aren't very useful. They help to plan better, and therefor be more productive.– superMOct 3, 2012 at 17:32
-
4@superM: I didn't say they weren't useful at all. They certainly are. I said that they're not worth much time expended. Working software is much more useful, so spend the vast bulk of your time on that.– pdrOct 3, 2012 at 17:34
-
@superM: Did you ever do a comparison between your estimations and the real values? This will tell a great lesson about the real value of guesswork (which an estimation is by definition). Estimation is a classical Pareto thing: You get a fairly good estimation in 20% of the time. Wasting any more time will make it only 5% better.– JensGNov 7, 2013 at 19:44
-
For me, the longer I work on a project, the better estimates I make. There are too many factors and some of those I can't control, and knowing those [project-specific] factors comes with experience. Sometimes you just can't escape estimating, and sometimes you're among those who suffer from your inaccurate estimates.– superMNov 8, 2013 at 8:04
In my experience, one of the core 'yeah, that really works' pieces of an agile approach is the 'Tasks should take less than a day' guideline. If you're estimating things that take longer than a day, you're going to be pretty far off.
Once you've broken them down so you can do that, you've done enough; regardless really of what those things are.
In the agile scrum methodology, Planning Poker is seen as an effective way of using the whole team to rapidly estimate the effort required for the user stories in a sprint (presuming this is what you are talking about). Otherwise, I wouldn't spend any more than a few minutes estimating a single task that is part of a user story.
I would highly recommend using this consensus-based technique if you are attempting to make estimations for a team of developers.
Planning poker means that you can get some pretty good estimates for every single user story within a single session (no more than 1-2 hours).
Do some reading on this and give it a try!
Also, as a general rule, no task in a user story should exceed 7.5 hours (a single day of work). If it does, you need to break the task into smaller tasks.
-
1Planning poker estimates Points, which are in No Real Units Whatsoever. Which sort of makes them analogue to how estimates really are; Wild Ass Guessery.– Warren POct 3, 2012 at 23:26
-
1The idea is that if we know that a 1 point task will take 7.5 hours, for example, then we can say that a 5 point user story will take 30 hours, and that a 10 point user story will take 60 hours. For example, we might choose one of the smallest tasks, and the estimated time can be assigned as the value of a single user story point. Then, we can use this user story as a basis for estimating larger tasks. If we think another task will take twice as long, we would assign 2 user story points (15 hours), and so on. Oct 4, 2012 at 2:13
I think it depends on what you need. If, for example, the resources allocation of your project depend on it (as was the case around here sometimes), it is better to do it carefully. In the other way if you are doing a project that does not have this kind of necessity you may not go into too much detail. Spending too much time on it is not a good idea cause to do an accurate estimation is very hard.
There is a famous concept called Cone of Uncertainty and Cone of Uncertainty at Wikipedia that says how much accurate an estimation usually can be. It is worth reading about.
What do you get out of your estimates?
Depending on what you work on, accurate individual estimates might be relevant (customer is paying you at the end of the week or task/story is blocking to others and a precise ETA is required) or not (you got 200 stories in the backlog, nobody is going to die if a story shifts for a week, and you're counting on estimate errors to average out ok over a large number of them).
Just spend the minimum amount of time to get an estimate that is good enough for your needs. There is no formula.
Personally, I consider than more than a minute or two means that you're probably estimating the wrong thing (split it up or plan discovery).
Actually you need estimation to help other stakeholders assign relative priority - so broad-based estimates that at least say task1 is roughly 3 times effort compared to task2, (even if in terms of hours its not very accurate in the end) are useful. Spend as much time is needed to understand what those tasks are (for achieving certain goals) and then having rough estimates for them.
Once you have relative priority, just focus on doing things and adjust estimates en-route. In other words, spend little time in up-front estimates, but do refine your estimates as time goes so that the project plan gives a good idea when what is going to get done.
Good estimates are the once that are based on facts not assumptions.
Thus, if you already had a similar project(s) and captured your previous estimation time, that might server as a good estimation base to start. However, depending on your project scope there might be unknown artifacts, which is better to clarify with BA or product owner asap.
It is also true to say that : Software Project Estimation is Inherently Inaccurate. However, there are some realistic estimation practices that might help:
- People who do the work, should participate in the project estimation
- Bring in the experts: Expert judgment is critical to project success
- Estimate large pieces as a range
- Use the Delphi Technique: This is a method that helps converge opinions of the team should there be a conflict in software project estimation.
- Keep in mind the cost
- Keep in mind the allocated resources available to perform the work
-
I have never observed a team or individual who did estimates that routinely (more than 50% of the time) turned out to be accurate within 10% of the actual time spent. Other people in other places claim successes that seem hard for me to imagine ever happening anywhere I ever worked.– Warren POct 3, 2012 at 23:27
-
"accurate within 10% of the actual time spent" - is actually very poor result. Also take into account the margin of error, that increases by complexity and external dependencies of the project.– YusubovOct 3, 2012 at 23:38
-
-
yeap, that is really big blow to have "accurate within 10% of the actual time spent"...– YusubovOct 4, 2012 at 2:09