Please login or join to subscribe to this thread
Perhaps I will not answer your question. But it is not an "effectie" estimation no matter the type of approach you use. Into each estimation you will have a component which is based on available information and that will determine the degree of uncertainty which is the amount of deviation or error you will get into the numbers. My recommendation is using Barry Bohem´s "Cone of Uncertainty" with your estimations.
Sergio recommendation to the "Cone of uncertainty" is a good one. To be "effective" here a couple of additional comments:
1. Wir estimation meetings the team increasingly learns and understand better the stoty content of the backlog and in incremental steps the overall "product picture" get more clear and precise what needs to be achieved.
2. Team estimates the features scope to get done.
3. During estimation new ideas and stories may arise.
4. Slices big backlog items in smallest parts possible in order to reduce complexity.
5. You estimate all not yet developed items - also those ones you estimated already (in order to include new knowledge about those ones.
6. Try to cover in your estimates the backlog items of the next 3 sprints with most detail you can apply.
1. With estimation....story content....
For a starter you should see this video on Agile Estimation.
Hopefully it triggers some thought process on either story point or value point
Published on May 12, 2014
Video by David Griffiths 2014
Hope this helps
If you are really interested in this subject and want to learn useful techniques I do recommend two books by Mike Cohn:
- User Stories Applied: For Agile Software Development http://www.informit.com/store/user-stories...t-9780321205681
- Agile Estimating and Planning http://www.informit.com/store/agile-estima...g-9780131479418
These two books are the "bibles" for real agile estimation. There is really a lot of useful information in these books. Highly recommended.
(Still as Sergio and Peter have already pointed out: an estimate is by its nature uncertain. An estimate is not a promise.)
The challenge I have getting to grips with estimating in this area is the governance level. How do you estimate the cost of a proposed development for the purposes of seeking approval to proceed and funding when the development pathway and even the end point are subject to change as work proceeds? Is this stage just handled in the same way it has always been, reserving the agile aspects of the work for the implementation stage?
I will check
For a software development project I currently tend to favour taking the old pre-study phase and divide it into 2 phases:
a) a shorter pre-study phase, as there will be much less detailed planning done this early in an agile project; and
b) an elaboration phase (or whatever you want to call it). In this elaboration phase you start to deliver user value by running sprints/iterations. After about 4-5 sprints/iteration you should have a reasonable estimate of the velocity. Now you can probably present a reasonable accurate cost forecast for the currently prioritised stories in the backlog. This is when there is enough information for the governance level to make the go/no-go decision.
If there is a go-decision the project can move from the elaboration phase into the real project work phase.
Naturally the scope may still change, but then it is either because stories are swapped to incorporate new higher priority stories and leave out lower priority stories or it is because of a deliberate decision by the governance level to increase the scope.
Effective implies a number of things. I'm going to presume you mean a mix of the team understanding size/complexity then also how you communicate this back to your stakeholders through planning and release planning so they know when they will get what they want.
The truth is from a PM side of the fence this doesn't matter the approach. There is Fibonacci (infinity estimation or capacity estimation) and t-shirt sizing. Personal preference for me is infinity estimation where the team agrees a what a 3 pointer is and estimated complexity to a definition of done based on relativity to said 3 point story.
There are two types of sizing estimation that you need to think of high level and low level. High level is a finger in the air sizing of the larger pieces that may or may not happen in the future, where as low level is the work taking place in the next 2-4 sprints. Think of this as progressive elaboration / s wave planning. In scrum / agile it's called a DEEP backlog (Detailed appropriately, estimated, emergent, prioratised)
What I tend to do for HLE is t-shirt size something like:
XS 1-5 days
S 1 -2 weeks
M 2 - 4 weeks
L 4 - 8 weeks
XL 8+ weeks
Then once the story is broken down closer to the time with the team / PO / BA etc and you employ INVEST (Independent, negotiable, valued, estimable, small, testable) and look at infinity estimations.
N.B This approach will mean as well the BA / PO does just enough in time as well and doesn't do a ton of work that might never happen!
Velocity and planning:
It's all good and well the team all agreeing what a XS or a 5 means but form a planning and reporting perspective it really means nothing nor are the business likely to care! What we care about is planning and predictability in an agile environment.
Now you can't take the size of an individual story because on a bell curve of predictability a 2 could be a 3 and a 3 could be a 2! What you can start to understand is that a team will deliver X points in a sprint. Once you have a settled velocity you can start to create burn up charts to understand stories completed and how long it will take to complete the backlog. you can also use communicative flow to predict this with an ever changing back log. Jira and other tools will do this for you which is nice but it's always good to know the theory here so you can draw it out when a stake holder asks about it.
In terms of predictability of velocity it's very hard to predict sickness etc and also how this will impact the team because it's about how the team work together not X person is ill so we will lose x number of days / hours of delivery. However you can perform capacity (hours everyone has in a sprint) over velocity calculations to get a velocity index. This will give you an index that will allow you to predict and measure not only if the team are getting more efficient (index goes up), are they settling into a good cadence, but it will also be a good indication if the team are over committing in a sprint when someone is off.
With a mix of these estimation tools you'll be able to support a team better but also plan and estimate time lines with the business.
The last and most important part in estimation is getting the business to understand this and that delivery on X date has changed to likely delivery in X month all things being equal!
Aswini, you might also want to check these other discussions.
Please login or join to reply