|
Better Estimates in 10 StepsPosted by Julio Gonzalez on 10/09/2009 in project management , Collaboration |
I’m not a fan of using story points, however, one way or the other, estimates are a very important step in any project and a key to delivering on-time. The result of not doing it is downright awful, and everybody in the team suffers the consequences. In this post I want to share the steps we follow to make estimates.
Without further ado,
- Get the whole team to learn what the user stories or features are all about. It is very important that everybody in the team understands all the features that go into a sprint. Clarify the requirements so that everybody understands in depth what they are estimating.
- The team must include an active Product Owner, otherwise do not proceed with the estimates.
- The Product Owner needs to answer every question the team raises. If the team doesn’t raise any question, then there is a problem. Keep at it until everybody understands all the stories in the same way.
- For every feature, have the team make three estimates: best case, worst case and most likely case, in that order. Order is important because you want to give people a chance to be their usual optimistic (best case) or pessimistic (worst case) selves. Once they get this out of their system, there’s a better chance that they can lean back and come up with a realistic most likely estimate. Once you have these numbers, use PERT to calculate the task’s ETA. Normally this is calculated as (Best Case + 4*Most Likely + Worst Case)/6. If you know from experience that the team tends to be overly optimistic or pessimistic you can change the factor to weight the calculation one way or the other.
- Promote a participative culture in your team. Ask, and encourage others to challenge estimates that seem out of range. Why is the estimate so high? Why so low? This discussion might uncover obstacles and opportunities that would normally go unnoticed.
- Keep cycling through the estimates until every single question that can be answered has been answered and each estimate falls has been sanity-checked by the whole team.
- BTW, besides better estimates, this process really cements down the team’s commitment to these estimates.
- Calculate the team’s capacity per sprint, Capacity = #team members * working hours * days in the sprint. It’s important to take into account vacations, holidays, planned personal time off, and whatever limits capacity.
- Once capacity is calculated, then you can figure out what features really fit in the sprint.
- To learn from your estimation process, keep track of metrics, especially deviations. Once you have history from at least three sprints, you can use these statistics to polish future estimates.
It is highly important that this be a commitment-driven process. In the end, the sprint goal must be crystal clear and the whole team must be on board with it. Given this commitment, the team will make sure that the sprint is delivered on time.
Bookmark
Email this
TweetBacks (Tweet this post)
Trackback(0)
TrackBack URI for this entryComments (10)
This comment's feedShow/hide comments
Never forguet to re-estimate
Very good advice, a point I would like to particularly stress is that it is very important to remember that estimating is not a thing you do once at the beginning of a project (because at that time you are at the moment with greatest uncertainty). You need to periodically revisit you estimates and adjust them based on the performance that you team has presented so far.
Also remember to re-estimate if you have increased (or decreased) the number of people available in your team, and keep in mind Brook's law: "adding manpower to a late software project makes it later" so do not assume that since you added more people to your project is going to take less time.
Also remember to re-estimate if you have increased (or decreased) the number of people available in your team, and keep in mind Brook's law: "adding manpower to a late software project makes it later" so do not assume that since you added more people to your project is going to take less time.
,
October 09, 2009
|
-
- +0
-
-
Do not spend too much time on estimations
Estimate at the beginning using UCP method.
It is accurate +-5%.
Then proceed with actual work.
Establish common lexicon early.
Enforce opennes
Hire one vertical slice architect with bacground in many domains.
Don't divide individable.
Don't reinvent the wheel, stick to process and other methodologies like RUP, SOMA,
SIMM, SOA, SOE, TOGAF, Zachman, etc
It is accurate +-5%.
Then proceed with actual work.
Establish common lexicon early.
Enforce opennes
Hire one vertical slice architect with bacground in many domains.
Don't divide individable.
Don't reinvent the wheel, stick to process and other methodologies like RUP, SOMA,
SIMM, SOA, SOE, TOGAF, Zachman, etc
,
October 10, 2009
-
- +0
-
-
accurate +-5%.?: If it is seems to good to be true, it probably is
Bran,
What you are saying is that if UCP is followed you hit the originally estimated plan with a maximum error of %5 extra time?
That means that if you calculated 3 "real" months for you project, that is 60 work days, you finish it max. 3 days later, without over budgeting, without coming to work any weekend, without any major bugs,and working only 8 hours a day (and with a system that does exactly what the user wanted a the beginning).
Truly amazing (an IMO very unlikely)... I really hope it is true for you, although in my experience most initial estimates have errors in the range of -25% to +400% due to the cone of uncertainty:
http://www.construx.com/Page.aspx?hid=1648
IMO, without re-estimation based on the performance of your team so far with the project initial estimates quickly become irrelevant...
What you are saying is that if UCP is followed you hit the originally estimated plan with a maximum error of %5 extra time?
That means that if you calculated 3 "real" months for you project, that is 60 work days, you finish it max. 3 days later, without over budgeting, without coming to work any weekend, without any major bugs,and working only 8 hours a day (and with a system that does exactly what the user wanted a the beginning).
Truly amazing (an IMO very unlikely)... I really hope it is true for you, although in my experience most initial estimates have errors in the range of -25% to +400% due to the cone of uncertainty:
http://www.construx.com/Page.aspx?hid=1648
IMO, without re-estimation based on the performance of your team so far with the project initial estimates quickly become irrelevant...
,
October 10, 2009
|
-
- +0
-
-
Estimating - a black art
Julio:
Great post. We follow a similar process. One thing that I've found very helpful is the concept of a "commit" where, halfway through the sprint, we revisit the list of user stories with the dev team and ask them to readjust the estimate if necessary and "commit" to the deliverable. Before that, it was difficult to get folks to think deeply about the requirements. 2 hours, 2 days, w weeks, whatever - the dev team wasn't really taking the estimates seriously. The idea of the commit meant that the developer would stay late, work weekends, etc. if behind, and kick off early if they were done ahead of schedule. Giving them a sense of responsibility and control has worked wonders for productivity and general morale.
Again, thanks for the excellent post.
Great post. We follow a similar process. One thing that I've found very helpful is the concept of a "commit" where, halfway through the sprint, we revisit the list of user stories with the dev team and ask them to readjust the estimate if necessary and "commit" to the deliverable. Before that, it was difficult to get folks to think deeply about the requirements. 2 hours, 2 days, w weeks, whatever - the dev team wasn't really taking the estimates seriously. The idea of the commit meant that the developer would stay late, work weekends, etc. if behind, and kick off early if they were done ahead of schedule. Giving them a sense of responsibility and control has worked wonders for productivity and general morale.
Again, thanks for the excellent post.
,
October 26, 2009
|
-
- +0
-
-
Thanks
Thanks for all your comments which are the real value of the blog post
Julio.
Julio.
,
October 26, 2009
|
-
- +0
-
-
Re:Never forget to re-estimate
Thanks Francisco, re-estimates are a very good point, most of the time there are tasks that take longer/shorter than estimated, It's very common that the task owner realizes something unknown about the task when (s)he is actually doing the job, then, is fair to do the adjustments needed and properly manage the expectations with your stakeholders.
However re-estimates needs to be carefully managed and they need to be done based on the right reasons.
However re-estimates needs to be carefully managed and they need to be done based on the right reasons.
,
October 26, 2009
|
-
- +0
-
-
RE:Do not spend too much time on estimations
I never used that method before, although UCP seems to be a good approach for estimates.
I'd say that time needed for estimates depends on the time needed for the team to clearly understand requirements and evaluate the involved tasks needed to achieve the goals.
In case the team get stuck you can always define some assumptions and manage them as the project progresses.
I'd say that time needed for estimates depends on the time needed for the team to clearly understand requirements and evaluate the involved tasks needed to achieve the goals.
In case the team get stuck you can always define some assumptions and manage them as the project progresses.
,
October 26, 2009
|
-
- +0
-
-
RE:accurate +-5%.?: If it is seems to good to be true, it probably is
Francisco,
The +-5% deviation seems to be something impossible, even more if you are at the very initial stage of the project and because the cone of uncertainty , giving an estimate at this stage specially if not all requirements are clear is highly risky, in this case I would give a range rather than commit to a target date. In the other hand using Scrum or any other agile approach will give you this kind of flexibility “Adaptability rather than Predictability”
The +-5% deviation seems to be something impossible, even more if you are at the very initial stage of the project and because the cone of uncertainty , giving an estimate at this stage specially if not all requirements are clear is highly risky, in this case I would give a range rather than commit to a target date. In the other hand using Scrum or any other agile approach will give you this kind of flexibility “Adaptability rather than Predictability”
,
October 26, 2009
|
-
- +0
-
-
, to be agile we should always prefer Adaptability over Predictability 
