Standard Spin on Story Points
There are a lot of good videos and articles out there about Story Points. They describe in various ways, what the presenter thinks story points are, what they’re good for, and how they’re used. I do not want to repeat that information here, too much. It’s all good stuff, but it always left me hanging.
Sure, I get that Story Points are for mid-range to long-range planning. I get that sizing is needed in the earliest stages of planning, and using “ideal hours” is impractical if not impossible until later, during iteration planning, when architects and engineers can decompose the problem at hand into measurable morsels of work. I get it.
Several things remained fuzzy for me, though, including the following:
- How does a team start sizing with abstract story points?
- How does the suggestion that they use the Fibonacci series for weighting the relative size or difficulty really work?
Epiphany (or Aha!): Abstract Decomposition
The answer to number one came to me when I was reflecting on a RallyDev help page. They may strongly disagree with what I’m doing with their lesson, or they may claim that what I’m about to share is what they had in mind all along. Either way, it came to me much later.
They point out that high level user stories can be characterized by the three dimensions, complexity, difficulty, and doubt, all of which they show in a Venn diagram something like this:
Three Dimensions of Sizing
Complexity is not the same as difficulty. It just means there may be a lot of moving parts to deal with. Yet no single part is necessarily hard to manage. Difficulty means that implementation might require some real puzzle solving, or the mastery of a new, non-trivial skill that no one on the team has yet mastered. Doubt means the requirements are still not clear, or at least not clear in how they should be realized.
RallyDev recommends that the planners take all of these into account, and come up with some visceral, overall assessment.
The implication is that these three dimensions are individually assessed, but the overall score seems left to intuition or a hunch. This is OK, and probably works for teams that have achieved some momentum and experience, but being my semi-anal self, I simply need to make this abstract sizing more concrete.
It’s simple. Just follow through and explicitly decompose these three on a scale of 1 to 10, and average the results, like this:
User Story 1
User Story 2
I figure we could start with that approach until some more Zen sensibility develops.
Now, I just need to figure out why the Fibonacci series works so well. Perhaps, one could move to that after getting some practice.