57228Re: [scrumdevelopment] Potentially Releasable Increment
- Sep 20, 2013Ron,
Good stuff as usual. I especially appreciate your reference to the Scrum Guide.
optional aspect of the DoD, it seems to me. Therefore it might fall into the realm of "useful advice about your Definition of Done", and not into the meaning of Potentially Releasable.>As for #3, that would be an
Well, the Guide mentions "useable" in several places... such as these:
You are on the right path in "smelling" that I made up my own definition of "useable". I feel like it is "useful" to further define "useable" so that Shu level Scrum users understand what it means. I'm having to go out on my own a little here because the Scrum Guide doesn't elaborate on what "useable" means. OTOH, it has been my experience that Shu level users get wrapped around the axle on "incremental" development -- and are stuck on this sort of view that "it's only useable if it has *all* the features", etc. I'm trying to create some daylight and understanding between "it must have everything" and "it must be releasable".
- "The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created."
- "At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.” It must be in useable condition regardless of whether the Product Owner decides to actually release it."
- "This Increment is useable, so a Product Owner may choose to immediately release it."
Anyway those are my thoughts, so I'd appreciate any further input you and others might have. Maybe there's a better way to convey what I'm talking about.-------
Professional Scrum Trainer
From: Ron Jeffries <ronjeffries@...>
Sent: Wednesday, September 11, 2013 5:26 AM
Subject: Re: [scrumdevelopment] Potentially Releasable Increment
Charles:On Sep 11, 2013, at 5:51 AM, Charles Bradley - Professional Scrum Trainer and Coach <chuck-lists2@...> wrote:
I wanted to throw out some thoughts I have on "Potentially Releasable Increment" as it's defined in the Scrum Guide, and see if others have similar or different views.
My current view is that a PRI includes the following:
Wrt # 3, in my current view, it is a "nice to have" if the increment looks seamless and there are *no* feature gaps at all.
- Available for immediate release. There is no more "finishing" or "release work" or "final testing" that needs to be done on the increment, such that the PO can push the button on the "deploy to production/users" process immediately after the sprint if she so desires.
- A Done Increment. The increment meets a Definition of Done that indicates a very acceptable and transparent level of quality for the software/increment.
- Useable by end users.
- This implies, at a minimum, something like:
- No "embarrassing aesthetic ugliness" that would cause any material amount of "product goodwill" to be lost by users
- No "horrible feature gaps^1" that would cause any material amount of "product goodwill" to be lost by users
- This implies, at a minimum, something like:
^1 An example of a feature gap for something like Amazon.com might be that you can add a new payment method, but the feature to select that new payment method during a purchase does not exist yet. I would consider this a feature gap, but probably not a "horrible feature gap" if that needed feature was coming within a few weeks or so.
Have I missed anything? Do you have similar views or different ones? Do you use different terminology?I think I'd begin with the Scrum Guide in this, as I would with anything where the topic was Scrum. To me, the July 2013 Guide says that the process is all about producing a potentially releasable increment of software that meets the team's Definition of Done. The guide does not define "potentially releasable". Perhaps it's a metaphor. More likely it means "capable of being released". Just guessing of course.If we must clarify the term, I think your #1 is the sole definition of Potentially Releasable: no finishing work required.
Some people, notably including but not limited to Dan Rawsthorne, say that PRI means it will only take one somewhat dedicated Sprint to get it ready to release. I think that approach too easily leads to a series of "Release Sprints" and do not recommend it.As for #2, every Sprint is required to create an potentially shippable increment that meets the Definition of Done. Therefore, the DoD can be thought of as the team's definition of what potentially shippable means to them. It seems clear from scripture that "needing no special release-oriented work" is always supposed to be part of the increment.As for #3, that would be an optional aspect of the DoD, it seems to me. Therefore it might fall into the realm of "useful advice about your Definition of Done", and not into the meaning of Potentially Releasable.But I think this is all about angels on the points of pins. The whole point of Scrum is not to be all definitional but to think about what we're trying to do, and to improve it. Or else the point is something else.
- << Previous post in topic Next post in topic >>