QH #5: Estimation Guidelines for Agile Software Development
QH #5: Estimation Guidelines for Agile Software Development
Basic guidelines for estimating work in agile software development
This is the fifth installment of my “Quick Hitter” (QH) series devoted to delivering a lesson or insight you can digest in a short amount of time.
Key Concepts
User stories and tasks require “pointing”. “Pointing” is the act of assigning story points to a given unit of work (e.g. user story, tech task). A story point generally represents a “personal day” of work, give or take a few hours. Typically this accounts for 6 hours of work on the sprint tasks/user stories and 2 hours of buffer for interruptions. Story points are assigned based on the assignee’s bandwidth, availability, and environment constraints.
Guidelines
An effective method I have used is the “Modified” Fibonacci for estimating user stories and tasks. The modified Fibonacci sequence is: 0, .05, 1, 2, 3, 5, 8, 13, 20, 40, 100.
Effective and useful estimates start by giving engineering teams clarity by:
Minimizing uncertainty. Engineers are comfortable giving estimates when there are minimal to no assumptions and clear constraints and requirements. This is a key role the product manager plays in the process.
Eliminating confusion. As the PM, aim to eliminate overlap and confusion in the requirements and use cases. Be very specific about the requirements and do not leave anything to chance. Follow the thought of the requirement through to completion.
From there, estimates should be based on two principles:
Quick and Clean - Avoid overanalyzing the estimate once the above are met. Spend minimal time on making the estimate.
Accurate, not precise - In alignment w/quick and clean, the estimate does not need to be perfect, just accurate. Provide a high and low estimate, and meet somewhere in the middle.
Anti-Pattern to avoid: Overestimating. When given more time than needed, that time will be filled with things like “gold plating” that aren’t necessary to deliver the feature. This doesn’t mean estimating as low as possible and incurring technical debt, but it does mean making estimations lean enough to avoid Parkinson’s Law (https://www.consuunt.com/parkinsons-law/ ).
Resources:
https://www.parabol.co/blog/fibonacci-estimation
https://www.mountaingoatsoftware.com/blog/why-the-fibonacci-sequence-works-well-for-estimating
https://www.lucidchart.com/blog/fibonacci-scale-for-agile-estimation
My Ask
Thank you for reading this article. I would be very grateful if you complete one or all of the three actions below. Thank you!
Like this article by using the ♥︎ button at the top or bottom of this page.
Share this article with others.
Subscribe to the elastic tier newsletter! *note* please check your junk mail if you cannot find it