Story Point estimation is a critical technique for project planning and team velocity tracking in an agile project.
Usually, to estimate the size of a user story , we tend to compare it with the standard user story which already has a fixed number of story points. We get the feeling how big the user story is by comparing it with the standard one, and then we get the story point number for this new user story.
However, user story point estimation more than often is quite confusing for developers. In blog: Quantitatively Measure Story Points in Color, Ethan Huang has introduced the challenges that could happen during user story point estimation, and he has provided a technique which could help us analyze and estimate story quantitatively.
There are still some challenges though:
– How to estimate research work such as developing a POC?
– Suppose there are different work types, like web development, ESB integration, and reporting in the same project, how shall we compare them and estimate them with the same measurement – story point?
– Also, for project management, can you tell how much research work in your project? How much routine non-research development work in your project?
These problems can be solved to some extent by adding the “Story Type” or “Story Implementation Type” concept into your story planning/estimation.
– In your product backlog or user story planning tool, add a new sheet “Standard Stories”, where you can define a table of standard stories. Each Story Implementation Type has at least one standard story and non-change story point with it.
– In your product backlog, add a column “Story Type” or “Story Implementation Type”.
– When estimate a user story , always refer to the “Standard Stories” sheet. Estimate it by comparing with the standard story of the same Story Type.
Benefits of this approach:
– Easier to estimate for developers.
– More accurate estimation.
– Clear view of total story points, as wells subtotal of each story type.
When to use:
When a project implementation requires disparate technologies, or requires significant research work.
Tips:
As “Story Implementation Type“ looks more from developer’s perspective rather than from user’s perspective. It is only a technique to help developers/project managers estimate more accurately. It does not help when gather requirements.
How do you think?
