Now that I'm at Pathfinder, many new clients are coming in through the UX door and they are not familiar with Agile. I often have to explain how estimating and story points work.
If you search the Internet, there are tons of links about Agile estimating and story points so it seems redundant to add another but I really wanted to blog about this, if only to organize my favorite references.
So here are four links that cover just about everything on the subject (plus they'll send you to other places anyway). And if you don't have the patience to comb through these references, I've added my basic explanation to customers at the end.
1.I know Anand Vishwanath from a long time ago. I value his overview for the thorough job it does of covering all the angles: http://bit.ly/MdH1tS
2. I love Dan North's post because it correctly, and effectively, shoots down that compulsive estimation marathon most companies want to indulge in: http://bit.ly/J9DvxF
3. Jay Fields is another former Thoughtworker who sums up the how-tos concisely: http://bit.ly/LbKy9Q
4. Mike Cohn is the ultimate writer in this area and this link leads to a chapter from his book on Agile estimation and planning, "Chapter 6: Techniques for Estimating": http://bit.ly/K6pvqQ
What I tell customers: We estimate expected effort, not hours. My teams count effort in points -- one is small, two is something more than small, three is something more than a one and a two, five is a large effort and going above five indicates the story is stated too broadly or contains enough unknowns to be manageable within an iteration.
Effort is either a measure of complexity (figuring out the unknown) or time spent on something that is naturally slow and tedious or a combination. Effort doesn't translate directly into hours but a team can use effort to figure out approximately how much can get done per iteration. It takes a team several iterations (2-5) to get a handle on their velocity (stories points completed per iteration) but you can use yesterday's weather to get a starting range for estimating a project.
Yesterday's weather comes from looking at what a similar team (size, experience) accomplished in a similar situation (familiarity with technology and domain). You only need one previous project to get this information. Use the averages - mean, mode, median - to figure out a likely range of outcomes and prioritize stories accordingly. Add 1-4 iterations for ramp-up (because both sides have to get up to speed) and 2-4 weeks for wrap-up (bugs, testing, and the unforeseen). Review and adjust the plan as you complete each iteration.
If you search the Internet, there are tons of links about Agile estimating and story points so it seems redundant to add another but I really wanted to blog about this, if only to organize my favorite references.
So here are four links that cover just about everything on the subject (plus they'll send you to other places anyway). And if you don't have the patience to comb through these references, I've added my basic explanation to customers at the end.
1.I know Anand Vishwanath from a long time ago. I value his overview for the thorough job it does of covering all the angles: http://bit.ly/MdH1tS
2. I love Dan North's post because it correctly, and effectively, shoots down that compulsive estimation marathon most companies want to indulge in: http://bit.ly/J9DvxF
3. Jay Fields is another former Thoughtworker who sums up the how-tos concisely: http://bit.ly/LbKy9Q
4. Mike Cohn is the ultimate writer in this area and this link leads to a chapter from his book on Agile estimation and planning, "Chapter 6: Techniques for Estimating": http://bit.ly/K6pvqQ
What I tell customers: We estimate expected effort, not hours. My teams count effort in points -- one is small, two is something more than small, three is something more than a one and a two, five is a large effort and going above five indicates the story is stated too broadly or contains enough unknowns to be manageable within an iteration.
Effort is either a measure of complexity (figuring out the unknown) or time spent on something that is naturally slow and tedious or a combination. Effort doesn't translate directly into hours but a team can use effort to figure out approximately how much can get done per iteration. It takes a team several iterations (2-5) to get a handle on their velocity (stories points completed per iteration) but you can use yesterday's weather to get a starting range for estimating a project.
Yesterday's weather comes from looking at what a similar team (size, experience) accomplished in a similar situation (familiarity with technology and domain). You only need one previous project to get this information. Use the averages - mean, mode, median - to figure out a likely range of outcomes and prioritize stories accordingly. Add 1-4 iterations for ramp-up (because both sides have to get up to speed) and 2-4 weeks for wrap-up (bugs, testing, and the unforeseen). Review and adjust the plan as you complete each iteration.
