Loading ...
Sorry, an error occurred while loading the content.

Re: [scrumdevelopment] Potentially Releasable Increment

Expand Messages
  • Adam Sroka
    #1 is closest to my definition, but like I said I think that the idea that there is no release work is potentially controversial. If it were up to me there
    Message 1 of 14 , Sep 20, 2013
    • 0 Attachment
      #1 is closest to my definition, but like I said I think that the idea that there is no release work is potentially controversial. If it were up to me there wouldn't be any, but I have been places that were doing Scrum reasonably well and hadn't tackled that. Also, there are domains where e.g. something has to be physically delivered to a customer. From a Lean perspective it makes sense to count that as part of your delivery stream in an attempt to optimize the whole, but from a Scrum perspective I think that the next Sprint can proceed even if a bunch of ROMs aren't burned and shipped. 

      I'm not really sure what #2 means given that the software would have to be tested and meet the definition of done for #1 to make any sense. 

      #3, to me, is up to the PO. If the PO believes there is business value to release it that's his call. He might choose not to because it lacks polish or any number of other reasons, but those are business decisions. AFAIK, that's why they chose to call it "potentially releasable" because the only thing missing when the sprint ends is that business decision. 


      On Fri, Sep 20, 2013 at 12:05 PM, 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 says
      I 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.

      -------
      Charles Bradley
      Professional Scrum Trainer
      Scrum Coach-in-Chief
      ScrumCrazy.com




      From: Adam Sroka <adam.sroka@...>
      To: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
      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:
      • "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."
      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".

      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.

      -------
      Charles Bradley
      Professional Scrum Trainer
      Scrum Coach-in-Chief
      ScrumCrazy.com




      From: Ron Jeffries <ronjeffries@...>
      To: scrumdevelopment@yahoogroups.com
      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:
      1. 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.
      2. A Done Increment.  The increment meets a Definition of Done that indicates a very acceptable and transparent level of quality for the software/increment.  
      3. 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
      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.
       
      ^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.
      Wisdom begins when we learn the difference between "that makes no sense" and "I don't understand". -- Mary Doria Russell











    • Markus Gärtner
      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
      Message 2 of 14 , Sep 20, 2013
      • 0 Attachment
        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
        Author of ATDD by Example - A Practical Guide to Acceptance Test-Driven Development
        Twitter: @mgaertne

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

        -------
        Charles Bradley
        Professional Scrum Trainer
        Scrum Coach-in-Chief
        ScrumCrazy.com




        From: Adam Sroka <adam.sroka@...>
        To: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
        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:
        • "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."
        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".

        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.

        -------
        Charles Bradley
        Professional Scrum Trainer
        Scrum Coach-in-Chief
        ScrumCrazy.com




        From: Ron Jeffries <ronjeffries@...>
        To: scrumdevelopment@yahoogroups.com
        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:
        1. 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.
        2. A Done Increment.  The increment meets a Definition of Done that indicates a very acceptable and transparent level of quality for the software/increment.  
        3. 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
        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.
         
        ^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.
        Wisdom begins when we learn the difference between "that makes no sense" and "I don't understand". -- Mary Doria Russell










      • Adam Sroka
        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
        Message 3 of 14 , Sep 20, 2013
        • 0 Attachment
          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
          Author of ATDD by Example - A Practical Guide to Acceptance Test-Driven Development
          Twitter: @mgaertne

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

          -------
          Charles Bradley
          Professional Scrum Trainer
          Scrum Coach-in-Chief
          ScrumCrazy.com




          From: Adam Sroka <adam.sroka@...>
          To: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
          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:
          • "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."
          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".

          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.

          -------
          Charles Bradley
          Professional Scrum Trainer
          Scrum Coach-in-Chief
          ScrumCrazy.com




          From: Ron Jeffries <ronjeffries@...>
          To: scrumdevelopment@yahoogroups.com
          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:
          1. 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.
          2. A Done Increment.  The increment meets a Definition of Done that indicates a very acceptable and transparent level of quality for the software/increment.  
          3. 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
          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.
           
          ^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.
          Wisdom begins when we learn the difference between "that makes no sense" and "I don't understand". -- Mary Doria Russell











        Your message has been successfully submitted and would be delivered to recipients shortly.