Completing a Release
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 remaining stories in the backlog for this release have a total of 100 story points. So QED, we have five Sprints remaining until we can release. (QED is from my old school days; Latin abbreviation 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 more clever than a shark.
It takes a clever, determined Product Owner to land the release. (And a clever team as well, but for now, we will focus on the PO.)
We know from long experience that the Product Backlog will (or should) change. New features will be discovered, and 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 work (maybe better to say 20% of the story points). Maybe not a perfect 80-20 rule, 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 problems (which we humans usually refuse to foresee) happen. And the completely unexpected happens with predictable 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 known 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 in a release, we are always still discovering what they want most, NOW. Customers always want more (although the “more” that they want is often less — for example, less complexity).
So, we must release ‘too soon’ in some sense. We must bite while the biting is good, and not wait for the perfect fish.