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).
3 comments:
I am wondering if you have an IT hat on when you talk about not focusing on completing work in the PB. If you have an end customer and a contract with user stories coming from the customer (which if you don't fulfill there could be legal implications, and no $$ if not delivered) everyone on the team needs to know what has been committed to, where that line is drawn for that set of stories in the PB for that release. Sure it iterates and is dynamic, however whatever chunk you (business plus customer) agree to needs to be delivered.
Catherine
Hi Catherine,
Well, in my experience, you have to complete the "contract" to get paid (fully). But also, most contract are made to be revised. And we know in SW development that we live and learn. So, often it makes business sense for all parties to revise the contract. (Meaning: not all the original PB items get done...before the revised contract is deemed "complete".)
Also, the contract typically specifies things at a high level. The Stories in the PB are typically at a (much) lower level. Clearly, the lower level things give us scope to move things into or out of the PB.
I like your last sentence. I would put the prior sentence this way: "Everyone needs to be dynamically improving the PB so that the more of what is valuable today gets delivered as soon as possible after the customer wants it." Not just that everyone knows, but that everyone contributes, perhaps in some small way, to improving the PB.
And probably I have just said what you meant in another way.
Regards, Joe
Many of the companies I work with use a "Change for Free" option in their contracts where work is completed in order of highest business value and the customer can insert new work items at any sprint boundary by removing low priority items of equal work. A half page addendum for each change is signed by the customer allowing contract tracability.
Companies that do not do this have huge cost overruns. In the U.S. some of my clients typically have 100% cost overruns. In Norway, last week one of them had just completed a 20M projects with a 10M cost overrun.
Now that agile practices are common and available everywhere, we have to question the competence of managers who do not use them. As Senior Advisor to a venture capital firm I train management in these strategies and we address it as a critical management issue at the Board level if the company does not use them.
Post a Comment