Estimating in Agile can be really tough, everyone in software development knows; borderline impossible for most. There are so many different styles of estimation, the reason being that no one method can work for any team or project.
- Story Points — where you 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 — this is where you try to estimate based on an ideal day; with no interruptions and work is completed efficiently.
- Task Decomposition — this method is where you would break a user story down into small tasks and try to estimate each little part of work that needs to be completed.
- Parametric Estimating — this uses statistical relationships between data and other variables, for example estimating volume by number of lines of code, multiplied by complexity multiplied by time.
- 3 Point Estimate — this is where you make an 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 — This is where you 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 be experimental and open minded.
Mike Cohn did a great talk on this, he gave the example of having a group of teams to each do a different type of estimation and work with it. After this, 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. For 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, and the remaining groups will keep the 3 left. Then if the group had to pick a 3rd time and a 4th time 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.
Trial and error — this is what Agile is all about after all!
This post was originally posted on: theproducthub.io
Please check my site to get the latest articles first!
About the Author
Product Leader. Over 10 years in product development; with experience in product management, UX & UI, product design, product & delivery methodologies and product leadership. A strong advocate in innovation, experimentation and building great products with the use of qualitative and quantitative research, putting an emphasis on a customer centric design and approach.