Q&A on Velocity, Part I

Having had many conversations about velocity (and many blog posts here and at the Industrial Logic Blog) one day I decided to write up an example of the conversation as if it were happening between two characters named A and B.

The first question asked by A was the first question about story points that a younger agile otter asked in his first XP project.

Most of the questions were asked by my younger self at some point or asked by someone I have worked with.

By the same token, the answers came from myself and people I know too. I've internalized these conversations to the point that I'm not sure what questions were mine and which were asked of me, and which answers were original and which came from mentors (managers, coaches, developers, etc).

Suffice it to say that I'm represented (at various points in my journey) by both the questions and the answers. As such, the point of the dialog between A and B is not to humiliate or pillory either A or B. The questions are pretty reasonable (most of the time) and the answers are not only honest but reveal deeper truths about software development and agile methods -- most of which one cannot acquire except through years of experience or mentoring.

At no time is it to be assumed by my publication of this series that I recommend using story points or velocity. I do not.  Even so, if people are using them, they should understand them at least until they realize that they are better off without.

So, here is part 1, annotated.

A: How long is a story point in real time?
B: How many did you do in your last sprint?
A: 23
B: Then, for you, it's a 23rd of a sprint
A: But the time before that it was 19
B: At the time it was 1/19th of a sprint.
A: But how long is it really?
B: We've determined that.

This was a major breakthrough for me early on. I didn't realize that roughly the same amount of work is done every week. Story points are a rough sizing of work, not a measurement.

I was once informed that every estimate involves not only effort but risk and learning. Risk and learning are often the larger part of each estimate. So when someone assigns a larger estimate, it is usually because they don't know how much they're going to have to learn to do the work or because they don't know what the risk is of it having wider unwanted effects on the schedule.

Many developers and managers refer to stories "blowing up" -- where it was estimated as a 2, but in reality, it was more like an 8 or 13 or 21. It's hard to know where the risks and learning will occur.

Sometimes a story assigned an 8 or 13 turns out to be easier and less risky than imagined, and the story is done in the time it would take to do one that would have been assigned a 2.

This doesn't mean that the team is doing a bad job, it really reflects more on the variability of the work items instead of the lack of consistency of the team.

When the team is not familiar with the source code of the project,  it is more common for greater numbers to be assigned and it for the stories to "blow up" or have defects. That's what happens when you don't know your way around.

But either way, the size of a story point isn't very meaningful -- it's a guess to begin with, and its "real size" is not only knowable in arrears, but is also variable. It is a unitless unit of measure, a bit of nonsense that people sometimes find useful for capacity planning.

It's almost always misused. An option is to stop using story points.



I'll see you in Part II