Re: [scrumdevelopment] Potentially Releasable Increment
- I agree. I think the Lean Startup ideas of getting quickly to MVP in order to learn from real customers, measuring what those customers do, and creating a continuous delivery pipeline to iterate quickly on that are incredibly valuable. It's seems to me, however, that Scrum's notion of a potentially releasable increment neither precludes nor requires any of that.If you wanted to use Lean Startup ideas with Scrum I think that would work. However, if you were in a domain where you felt that you couldn't or shouldn't do that it is still possible that you could be doing Scrum.I can think of a number of valid situations where that would be the case. For example, in some environments customers refuse to take upgrades outside of a fixed schedule for practical business reasons (Sometimes they do it for impractical reasons too... perhaps more often... but there are valid cases.) In some mature markets you don't have a viable product unless you implement key features that the market leaders have (Competing here needs a strong business case, but that can happen.) In the embedded market sometimes hardware development lags software development, particularly when dealing with third parties. Etc.On Fri, Sep 20, 2013 at 1:41 PM, Markus Gärtner <mgaertne@...> wrote:I would be fine without #3 for the sake of evaluating that we are on the right track with the ideas of those new areas of features around. I think a PO also should know something about LeanStartup int his regard. #3 appears to conflict that.Best Markus--Dipl.-Inform. Markus Gärtner
On 20.09.2013, at 17:05, Charles Bradley - Professional Scrum Trainer and Coach <chuck-lists2@...> wrote:> As you probably know by now I don't much care what the Scrum Guide saysI did know, in the back of my mind, but I think it's good that you keep reminding/clarifying -- because we all forget things from time to time. (I had forgotten that about you, but now my memory is refreshed)
Part of why I'm trying to clarify here is to coach PO's, especially "Shu level" PO's. I think that most Scrum users pretty well understand #1 and #2 from my "attempt at describing what PRI means" -- it's #3 that I find most Scrum users (and especially PO's) don't really understand. To me, if you haven't satisfied #3, then you don't have PRI. This kind of mindset is key for a PO to understand, because they can end up ordering the backlog in such a way to make a PRI not be PR. OTOH, we need to keep the "waterfall mindset" from setting in to think that a system can't be developed incrementally.
Having said all of that , my description of PRI is much more useful in the context of greenfield development than brownfield. Often #3 comes to a PO naturally when in brown field mode, but not as much in a greenfield mode.
Professional Scrum Trainer
From: Adam Sroka <adam.sroka@...>
To: "email@example.com" <firstname.lastname@example.org>
Sent: Friday, September 20, 2013 9:54 AM
Subject: Re: [scrumdevelopment] Potentially Releasable Increment
As you probably know by now I don't much care what the Scrum Guide says... however, when people ask me what "potentially releasable" means my usual answer is this: if the PO looked at it and said, "Yep, that's good, let's release it," would you say, "Okay," or would you say, "But wait, we have to do X, Y, Z first?" If the answer is "Okay" that's potentially releasable. If there is significant work that still has to be done before release then it's not.The one area that is a little less clear to me is whether it should be acceptable to have a complex and time consuming release process that happens after that "Okay." If it were up to me we would just click a button and it would be out in the wild, but I recognize that that reflects an XP mindset and not necessarily a Scrum mindset.On Fri, Sep 20, 2013 at 11:46 AM, Charles Bradley - Professional Scrum Trainer and Coach <chuck-lists2@...> wrote:Ron,
Good stuff as usual. I especially appreciate your reference to the Scrum Guide.
Re: #3>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.
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 IncrementCharles: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.