The exercise of putting “point” values on stories is a hallowed one in Scrum circles.  And rightly so – it is a powerful exercise.  Because of its marked simplicity and the underlying wisdom it embodies – it yields three important fruits, while avoiding some common but deadly software-delivery traps.

Story Pointing is first and foremost a discussion around the details of creating a particular piece of software.  The Story Point (and I’m assuming some familiarity with this exercise here) is a metric of relative complexity.  A team giving itself the mandate to arrive at this metric will instantly create deep conversation around details.

This brings impressions about the impending implementation to the forefront of peoples’ minds, turns intuition into explicit discussion, and generally drives powerful group learning.

Secondly, it pushes toward understanding the amount of scope (e.g. what size of story) is meaningful to entertain in this kind of discussion.  So, for example, a story point value of over 60 (or whatever the number is for a specific team) may mean that the story needs to be broken down into smaller parts in order to have meaningful discussions around the details of the implementation.

And lastly, the number of points in a sprint can begin to give a rough prediction of future throughput.  This allows a certain degree of anticipation and planning to start happening for stakeholders.

It does all of this while avoiding setting unrealistic expectations (which happens a lot when estimating with time values), and while not assuming or mandating the specific individuals working on the story.

Story Pointing is awesome.  But what I really want to do with this post is to save you a little time and effort.  And I want to do this by suggesting something ostensibly radical, but that I believe if you look a little deeper is only the next logical progression.  I’d like to suggest that you…

Do the Story Pointing Exercise but get rid of the points.

Huh?  Have you finally lost it, Kyle?

No – well I don’t think so – but follow me on this for a sec…

The usual series of Point values available goes something like: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 and (Infinity).  Not quite Fibbonacci – but it captures the idea that the bigger something is the less we can think specifically about small steps in complexity.  Great – so far so good.  If something is “Infinity”, we need more information and it needs to be broken down to make sense out of it.  It’s easy to see how the exercise works; we assign points to stories.  And it’s easy to see how the advantages listed above follow.

Now what if we took the 100 and INF cards and threw them out, and just accepted as a new rule that if it’s more complex than a 40, we have to break it down smaller before we can make sense of it.  Does that meaningfully alter the advantages that we noted above?  No – discussion will still be driven, velocity predicted, and all without triggering any of the pitfalls.

Practically speaking, the last few teams that I’ve worked on – they went further.  We never really  used anything beyond 13.  And even 13 is typically looked upon skeptically, in terms of being able to analyze the story in a meaningful way.  So what if we throw out 20 and 13 as well?  Anything over an 8 needs to be broken down smaller.  Have we lost out on any of the advantages yet?

Before we go any further – I’d like to highlight that the act of breaking a story down is as potent in terms of driving conversation as putting complexity numbers on them.  If you need to understand the details as a group to put a complexity estimate on a story, you even more need to understand details to break a story smaller.

So – if we would have otherwise had any stories larger than an 8 – we will have broken them down, and thus driven the conversation around them to a greater degree than if we’d put those higher level points on them.  So not only have we not lost anything by reducing our potential point values to 0, 1, 2, 3, 5, 8…we’re actually getting into higher quality discussion because of the breakdown of the larger things.

And if we remove 8 – have we lost anything?  Nope – again we gain.

5? Same.

3? Same.

2? Same.

Now we’re down to 0 and 1.  0 is trivial – we know when something doesn’t involve work, and there’s no reason to talk about that. Which leaves us with 1….if something isn’t a 1 we break it down further until it is.

Our pointing exercise is now – what point value is it?  Oh it’s more than a 1 – let’s break it down again.

Though, that wording is confusing – I’d suggest we make a slight semantic transformation, and simply ask “is this a small, nearly trivial story, or is it not.”  If it’s not, we break it down further.

It follows – but to make it explicit – that velocity planning is now simply counting stories, because they only have one possible value.

The time-saver with this – is the up-front savings of not having to teach people about the story pointing exercise (if it’s a shop that hasn’t done scrum before).  And the ongoing savings of simply giving a thumbs-up/thumbs-down on every story when you groom, as opposed to trying to arrive at a point value and also break the story down.

And thus we have story pointing….without the points.  And with all the same advantages.  And streamlined for the new millenium.  Story-Pointing++, if you will.  All the same great taste, half the calories.  Ok, I’ll stop.

Here’s to writing great software!