I have combined personal insights for fixed price (-negotiable scope) projects with practices from eXtreme Programming and Scrum in my My.Fragility framework.
The main estimation steps from the framework’s Product Backlog Estimation model were highlighted in my Definition Of Agile Planning. But the model also implies at least an understanding of some definitions.
After my definition for User Stories here’s how I use Story Points:
- Story Points equal ideal time (“ti”). But using ‘Story Points’ might prevent people from confusing it with realistic time. The eXtreme Programming notion of Gummy Bears (“Bg”) might be a bit too abstract, although it’s fun to use.
- Ideal time is the development time for a User Story without breaks, questions, problems or interrupts of whatever nature. Spending every minute of every working day on productive coding.
- Ideal time is mulitplied with Velocity (“v”) to estimate Planning time (“tp”). In my experience, an overall velocity of 2,5-3 results in a realistic number of planning days.
planning time (“tp”) = ideal time (“ti”) * Velocity (“v”)
- An alternative definition of Story Points is the number of productive coding hours per day. This is generally accepted as maximum 5-6. Velocity is then expected to be around 1,33.
Note I generally apply an overall Velocity to all User Stories, although my model allows a specific Velocity per User Story, e.g. depending on the expected complexity.