Estimating in agile can be really tough, everyone in software development knows; borderline impossible for most. Currently, there are so many methods of estimation and no one method can work for any team or project.
Styles include:
- Story Point Estimating : Measure the complexity of a user story based on comparison. This method often uses the Fibonacci sequence and a game called Planning Poker.
- Ideal Man Days Estimating : Estimate based on an ideal day; with no interruptions and work is completed efficiently.
- Task Decomposition Estimating : Break a user story down into small tasks. Try to estimate each little part of work that needs to be completed.
- Parametric Estimating : Use statistical relationships between data and other variables. By estimating volume by number of lines of code, multiplied by complexity multiplied by time.
- 3 Point Estimate : Estimate based on previous experience, and come out with 3 outputs. Best case scenario, worst case scenario and probably scenario. These are combined to give a probability for completion.
- Experienced Senior Programmer Days Estimate : Estimate what you think an experienced programmer would estimate. This is similar to ideal man days, only you are estimating what someone else would estimate.
Estimating in Agile: What Works Best?
As I said, not every style of estimating in agile will work for each team or project. The advise I would give to you is to experiment with estimating.
Mike Cohn gave a great talk on this. He asked a group of teams to apply a different type of estimation and work with it. After that, get everyone to discuss, then pick again another style of estimation. What you will notice is that new groups will start to form, and methods will be abandoned. An example if there were 4 teams; one doing ideal man days, one doing story points, one doing parametric estimating and one doing 3 point estimating . After the first round people might clearly see that parametric estimating doesn’t work. The remaining groups will keep the 3 left. If the group had to further times eventually you should come up with a method that everyone agreed worked based.
This is something that I fully encourage with teams I work with. Be experimental, try new things and don’t be afraid to fail. Experimentation allows you to make more data driven decisions and learn from experience.
Experiment with estimating, use trial and error — this is what Agile is all about after all!
Social Media
Please check me out on social media:
