Velocity and Story Points

Should I have titled this "Fun" or "Playing the Game of Scrum"? I might well have done that.

Introduction

There seems to be a lot of misunderstanding about Scrum, and more specifically about Velocity and Story Points.

There is also a lack of understanding about BV Points as well, but let's save that for another post.

The short version:

• Scrum is a game.
• To make the game fun, we score points in the game. A game is a sprint.
• At the end of the game, we can see if we won or lost.
• This has to do with human nature, and the kinds of games people like to play.
• And it has to do with Learning!

Goal: You win or you learn. There is no losing, well, assuming you actually do learn and get better when you do not score enough.

Longer Version

People enjoy games. Scrum, on the cover of the Scrum Guide, declares itself a Game. Modeled, as you know, on Rugby a bit. And related to the Scrum formation in rugby. (Don't take these metaphors and comparisons too far!)

People are more engaged, and they learn better, if they are having fun and playing a game. And our people are knowledge workers, and the most important thing they do is LEARN. (Yes, they do have to convert the learning into what Scrum calls "the product".)

So, Scrum creates a game each Sprint.

At the beginning of the game, in the Sprint Planning meeting, the Team decides how many points (story points) it thinks it can score this Sprint, everything considered.

The initial idea of the capacity of the Team is the average number of Story Points the Team has scored over the last 3 (or 4) Sprints. This average is to make reasonable accommodation for the vagaries of life. How unexpectedly, things go up and down. Aka "normal variation". (Cf. Deming) This average is called the Velocity of the Team (as of the Sprint just ended).

In addition, based on discussion and expectations of various things, the Team can decide to go for a bit more than the average or a bit less. For a good reason.

Examples of why more or less:

• Team members will be OOO more this Sprint (or less).
• An impediment has been fixed.
• The PO will not answer questions as much, as fast this Sprint (or vice versa).
• The SM will fix "blockers" more this Sprint

The Team also should identify tasks for the user stories (accepted for the Sprint). And estimate them in hours, perhaps. And use an hours capacity measure to see if they think all the tasks can reasonably get done in the Sprint timebox. (My example is 2 weeks; 10 business days.)

Then the Team commits. (Yes, it is more complex than this. This is KISS for the moment.)

And then the Team does the best it can to fulfill, as adults, the commitment they made. A commitment for only 2 weeks.

As in all games, life is not fair. You win some, you lose some.

Let's say the team commits to 20 Story Points.

Then, if the team "scores" 20 SPs or more, they WIN! A small win! Yippee! We get to celebrate. Winning is a great way to build a better team.

More interesting (at least to me) is: what if they score less than 20 SPs? Well, in sports we would say they lost. But to us, with knowledge workers, we say "they learn". They work on improving (fixing impediments is a classic way, but of course not the only way).

They figure out how to be less imperfect!

Incentive? They want to win the next f-ing game! They are competitive. (And engaged.) And, like any decent sports team you have ever rooted for, they know they can become better.

I recommend they set the bar (commit to the right amount of SPs) so that they tend to win > 50% of the time. Why so low? Because we want them to focus on improving as much as reasonably possible!

"Many a tear has to fall, but it's all in the game." Yes, it takes some emotional maturity.

Remember this from childhood: How your parents told you something like: "You win some, and you lose some. But you always do your best."

So, with a willing suspension of disbelief, the Team plays the game as if it were real. And in this play, we rise toward perfection. And, more importantly, they fulfill the great law: It is more blessed to give than to receive. That is, they take pride in delivering better and better stuff to the customers, who clearly need it and want it. (Well, at least more than in the past.)

Scoring Points

Each user story has an assigned story points number, of course. Which the Developers estimated and re-estimated, until they got "all" the information (they thought they needed). So, the final estimate should be "better than usual". And the stories should all be small and roughly the same size. Example: In the sprint we have 4 stories at 3SP each, and another 4 stories at 2SP each. For a total of 20SP of commitment.

The Team earns SPs toward the "score" in the current sprint by completing a story. A story is complete when it meets the criteria in the DOD. Then, we "earn" the 2SP or 3SP of that story, as the case may be.

Short Version on Wide-Band Delphi Expert Estimation

How does the Team estimate the Story Points?

We play Planning Poker, of course. Aka, wide-band Delphi expert estimation.

We get the best experts we can. In this case, the Developers. At any one moment, the Developers grab quickly the best info they can.

They compare the New Story to the Reference Story (suggestion: the Reference Story should be 1SP, ie, relatively small). They can talk to the PO about what is "in" the New Story. Perhaps others. They can make assumptions (eg, about technical issues). [Suggestion: definitely confirm or correct these assumptions later.] And then they vote using the Fibonacci cards.

If all 5 Developers [I assume in a full Team of 7 people] are within 3 consecutive Fibonacci numbers (ex: all votes are 2, 3 or 5), then add up the numbers from all the voters, and divide by 5. And round to the nearest integer.

This may take 3 or 4 rounds of voting, as explained next.

If they do NOT come within 3 consecutive Fibonacci number (ex: 2-3-5-8), then the two extremes must explain why they are so low or so high. Others, too, may share knowledge. (This sharing of knowledge in the game of Planning Poker is an awesome thing!)

Then the Developers vote again (the next round). And so forth.

Over the days and weeks, the Team should always be trying to gather all the needed information about a user story, so that the SPs on a story are more accurate. A better guess at the relative "work" that will actually be done. The PO helps on this as well. (Cf. Definition of Ready).

As an example, a story might be voted on 3 times: when initially identified, after a couple of Sprints, and then just before it goes into the next sprint. By that last vote, we hope it is small and the SP estimate fairly accurate. Or, at least within one standard deviation (wink to you Prob and Stats jocks!). This means that the highs and lows offset each other, and so, when the commitment is 20SP across 8 (or more) user stories, the 20SP becomes fairly likely to happen.

Conclusion

We covered a lot.

Let's focus on the fun, the various games we are playing, how the games get the Team engaged, how the Team learns more and faster, and remembers it better.

And how, by winning and losing the Game (within the Sprint), this enables the Team to become better fairly fast!

One final thought. Some of you know sports well. You know that to play your best, you need some adrenaline, but you also need to be calm. You need to manage your stress.

Likewise, we use these tools (and other tools) to keep the Team in the "good stress" zone. The point is NOT to over-stress the Team. Rather the opposite: To try to get the Team in the "good stress" zone. This is a surprising observation to many people. (Did I bury the lede?)

Have fun with it! Be proud of delivering more to your customers! (And having, overall, a better life for the Team.)