Completing a Release

June 24, 2009

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 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.

 

 

« « Recommended Reading – June 2009 || Fun & Success – Learn Scrum » »

Posted in: agile business, Release Planning
Tagged:

3 thoughts on “Completing a Release”

  1. Catherine

    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

    ↓
  2. Joe Little

    Hi Catherine,

    Well, in my experience, you have to complete the "contract" to get paid (fully). But also, most contracts 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

    ↓
  3. Jeff Sutherland

    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.

    ↓

Leave a Reply