There are more than 1 ways of estimating stories. Here is 1 way that I like:
Relative sizing:
Let's begin by taking an example story - As someone preparing to run a marathon, I would like to run 1.5 miles, so that I can build my stamina.
Now, lets say I have 3 'developers' on my team, with varying levels of stamina. Each person will take different amount of time to complete the story. But, if we were to call this level of effort as a "5", we take the amount of time each person takes to complete the work, out of the picture.
Let's say this story is your reference for relative sizing. When the developers estimate a set of stories, they can estimate the level of effort a story will take by comparing with the reference. If the level of effort is more, they can pick the next number in Fibonacci series (8). If it is less, pick the earlier one (3). If the estimate level is much much more, pick 2 numbers ahead (13).
Value the aggregates:
A sum of story points that the team completes in a sprint, averaged over a few sprints is your velocity. This aggregate of story points is valuable to the team as one of the data points for sprint commitments.
If stories targeted to a release are estimated, the aggregate is valuable, because it allows for some predictions on when the body of work will be ready to ship. For example, if a set of stories is sized to 1000 story points, and your velocity is 100 story points per sprint, you can say that it may take 8-12 sprints to complete that body of work.
To conclude, I would discourage scrum masters from going down the route of assigning X days = Y story points. Instead, value relative sizing and aggregates of story points.
| Rate this post! |
☆
|
☆
|
☆
|
☆
|
☆
|
