Completing a Release

OK, so we have a known velocity in Story Points. And, having that, it is an exercise for a 6 year old to figure out how many more sprints until the release.

Example: We have a velocity of 20 and the stories in the backlog for this release have a total of 100 story points, so QED, we have 5 sprints remaining until we can release.

[QED is from my old school days, meaning "which was to be proved".]

Fine, for a shark, a simple project manager or a 6 year old.

What's the problem, you say?

In real life, we need to be cleverer than a shark.

It takes a clever, determined Product Owner (in Scrum terms) to land the release.

We know from long experience that the Product Backlog will (or should) change. New features will be discovered, the customer will "know it when he sees it" (a law of software "requirements"). And "stuff will happen" such that the current known velocity will change.

Most importantly, the PO (Product Owner) will be executing the Pareto Rule, which says that 80% of the value comes from 20% of the stories (maybe better to say 20% of the story points). Maybe not a perfect 80-20 rules, but all those stories slated for the release are NOT required.

Side note: What can happen to velocity? First, it should improve as we remove impediments. Second, "stuff happens" and the foreseeable problems (which we refused to foresee) happen. And the completely unexpectable happens with known regularity (and perhaps some unknown frequency as well).

Let me emphasize again: The PO should dynamically be looking at the product as it grows to determine the Minimum Marketable Feature Set (MMFS) to release. This is a very dynamic process of discovery. Or should be. When you are creating something for the first time, there is always plenty to learn. (Or, if you waited for the "perfection" of the so-called requirements, you probably waited way too long.)

For a given product, we hope there will never come a day when we are finished improving it. When all the stories are done. We are always discovering what they want most NOW. Customers always want more (although the "more" that they want is often less...example: less complexity).

Should we invest in a better Product Owner?

I won't bore you with the calculation, but...

If you assume that a better Product Owner can:
* increase the value of Product Backlog items (stories) by 20% on average
* identify the Pareto curve partially in the Product Backlog, so that an 85-33 rule applies
* and if we assume that the team costs about $1,000,000 per year (all-in) and delivers, before the better PO, about $3,000,000 per year...

...then, what happens?

The team is now able to deliver $3,000,000 "projects" three times per year. Thus, this new PO has tripled the business value delivered by the team.

So, how much could you afford to invest in that better PO to get those results? Probably more than $1,500 (eg, for a Certified Product Owner course). And, while the course is good, I suspect that most Product Owners need more than just the course to get those results (eg, perhaps some coaching from someone really good).

So, what's the first impediment to doing this?

What I find is that most firms think of their IT department as a cost center. And thus they have no concept of BV delivered by IT, much less metrics around that. So, I am suggesting that just getting estimates of BV (and telling the team) and then measuring (even if only roughly) the BV actually delivered would be a big step in the right direction.

BV does not have to be measured in money. At least not initially. Depending on your firm, other direct metrics would be more meaningful. Then you need some experts to give you a rough estimate of the money value of those benefits.

Knowing the BV delivered of each team might be kind of important right now. In more ways than one. Go talk to your Product Owner about that today.