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

Potentially Releasable Increment

Expand Messages
  • Charles Bradley - Professional Scrum Trai
    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
    Message 1 of 14 , Sep 11, 2013
    • 0 Attachment
      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?

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


    • Markus Gaertner
      Depending on the state of the development, #1 is usually hard for them when they get started with Scrum. That said, when starting with Scrum the push of a
      Message 2 of 14 , Sep 11, 2013
      • 0 Attachment
        Depending on the state of the development, #1 is usually hard for them when they get started with Scrum. That said, when starting with Scrum the "push of a button release" is usually an ideal, that needs to be addressed over time once the team starts to get over the "getting familiar with Scrum" hump of pain towards the "let's start improving things" stage of team building. At that point, I would expect the team to expand their Definition of Done to the degree that "push of a button release" becomes more realistic.

        That said, I think #1 and #2 play together with each other in your model.

        Best
        Markus


        On Wed, Sep 11, 2013 at 11: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?

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







        --
        Dipl.-Inform. Markus Gaertner
        Author of ATDD by Example - A Practical Guide to Acceptance Test-Driven Development
      • Tim Wright
        I m not sure I entirely agree with #3. For example, I heard about a project team making an ordering/invoicing system. They went live without any monthly
        Message 3 of 14 , Sep 11, 2013
        • 0 Attachment
          I'm not sure I entirely agree with #3. 

          For example, I heard about a project team making an ordering/invoicing system. They went live without any "monthly statement" feature. That's a clear feature gap. However, they knew they could build that feature by the time it was actually needed by the business.

          (this is potentially a "friend of a friend" type story - but even if it's not real, it illustrates the point quite nicely :)

          Tim


          On 11 September 2013 22:05, Markus Gaertner <mgaertne@...> wrote:
           

          Depending on the state of the development, #1 is usually hard for them when they get started with Scrum. That said, when starting with Scrum the "push of a button release" is usually an ideal, that needs to be addressed over time once the team starts to get over the "getting familiar with Scrum" hump of pain towards the "let's start improving things" stage of team building. At that point, I would expect the team to expand their Definition of Done to the degree that "push of a button release" becomes more realistic.

          That said, I think #1 and #2 play together with each other in your model.

          Best
          Markus


          On Wed, Sep 11, 2013 at 11: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?

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







          --
          Dipl.-Inform. Markus Gaertner
          Author of ATDD by Example - A Practical Guide to Acceptance Test-Driven Development




          --
          Tim
          021 251 5593
        • Ron Jeffries
          Charles: ... 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
          Message 4 of 14 , Sep 11, 2013
          • 0 Attachment
            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

          • Adrian Howard
            Hi Tim, ... [snip] I ve seen this many times. For example one project I worked on involved a quarterly subscription. We chose to release the initial version
            Message 5 of 14 , Sep 12, 2013
            • 0 Attachment
              Hi Tim,

              On 11 September 2013 11:11, Tim Wright <tim@...> wrote:
              For example, I heard about a project team making an ordering/invoicing system. They went live without any "monthly statement" feature. That's a clear feature gap. However, they knew they could build that feature by the time it was actually needed by the business.

              (this is potentially a "friend of a friend" type story - but even if it's not real, it illustrates the point quite nicely :)
              [snip]

              I've seen this many times. For example one project I worked on involved a quarterly subscription. We chose to release the initial version without *any* of the code to actually implement renewals, and that way we could spend the resources we would have spent on those features on other features (notably some tweaks to the UI that helped with navigation & SEO).

              In fact by the time that the time for the renewals came around the client had changed their business model for the product from a subscription system to a value add on another service product. If we had built it - it would have never been used.

              ... and in general "product goodwill" is a bit fuzzy. I'm spending a lot of my time ATM in startup and new product contexts. We're still figuring out what our product is and what our market is. We're more interested in learning than in polished features. The whol concept of "product goodwill" is being defined.

              Scrum left the precise definition of what counts as a potentially releasable increment up to the PO/team. And that's the right place for it I think. It's very context dependent.

              Cheers,

              Adrian
              -- 
              adrianh@... / +44 (0)7752 419080 / @adrianh / quietstars.com
              Subscribe to the latest Agile & Lean UX news here > http://is.gd/KREt5S


            • Seyit Caglar Abbasoglu
              Terms embarrassing and unacceptable are generally very open to debate. I believe it would be a real challenge putting them into DoD and expecting everyone
              Message 6 of 14 , Sep 13, 2013
              • 0 Attachment
                Terms "embarrassing" and "unacceptable" are generally very open to debate. I believe it would be a real challenge putting them into DoD and expecting everyone to have a shared understanding of what it means for work to be complete.

                Besides as Adrian said, especially for startups which are creating a new market, these terms don't have a solid meaning at all. I've seen a lot of times a visual that considered as "Embarrassing" or "Unacceptable" by some members of the team turned out to be quite acceptable or even loved by target audience. More than that I've seen a feature turned out to be completely useless in such a way that it is thrashed immediately after release, thus wasting all the side-features and visual work to polish it.

                By following your Amazon example, to make "Unacceptable Feature Gap" less ambiguous, perhaps team might add "A feature (user story?) must deliver value to the end user" to DoD?


                On 12 September 2013 22:34, Adrian Howard <adrianh@...> wrote:
                 

                Hi Tim,

                On 11 September 2013 11:11, Tim Wright <tim@...> wrote:
                For example, I heard about a project team making an ordering/invoicing system. They went live without any "monthly statement" feature. That's a clear feature gap. However, they knew they could build that feature by the time it was actually needed by the business.

                (this is potentially a "friend of a friend" type story - but even if it's not real, it illustrates the point quite nicely :)
                [snip]

                I've seen this many times. For example one project I worked on involved a quarterly subscription. We chose to release the initial version without *any* of the code to actually implement renewals, and that way we could spend the resources we would have spent on those features on other features (notably some tweaks to the UI that helped with navigation & SEO).

                In fact by the time that the time for the renewals came around the client had changed their business model for the product from a subscription system to a value add on another service product. If we had built it - it would have never been used.

                ... and in general "product goodwill" is a bit fuzzy. I'm spending a lot of my time ATM in startup and new product contexts. We're still figuring out what our product is and what our market is. We're more interested in learning than in polished features. The whol concept of "product goodwill" is being defined.

                Scrum left the precise definition of what counts as a potentially releasable increment up to the PO/team. And that's the right place for it I think. It's very context dependent.

                Cheers,

                Adrian
                -- 
                Subscribe to the latest Agile & Lean UX news here > http://is.gd/KREt5S



              • Charles Bradley - Professional Scrum Trai
                Markus, I completely understand  your viewpoint, and essentially agree, with this one subtlety: IMO, and I think in the Scrum Guide authors
                Message 7 of 14 , Sep 20, 2013
                • 0 Attachment
                  Markus,

                  I completely understand  your viewpoint, and essentially agree, with this one subtlety:
                  IMO, and I think in the Scrum Guide authors' opinion(speculating of course), you are not doing Scrum until you are in conformance to the Scrum Guide.  When a team or org starts on the "March to Scrum", they will often be doing "not-Scrum" for a while...in many areas. At some time later, they can actually "do Scrum."(and be in conformance with the guide)  I sometimes call this the "bridging period".  As such, a "bridging" strategy might be that their DoD cannot meet the below characteristics of a PRI.  This is one of the reasons I posted the question and requested feedback.  Obviously "bridging strategies" can turn into "permanent bad habits", which is definitely something we don't want.  This is one of my reasons for using the term "bridging strategy", to make it transparent that this is "not Scrum" -- it's a strategy to get us across the bridge from doing <whatever we used to do> to "not Scrum"(on the bridge) to  "doing correct Scrum."(over the Bridge, and where we then start to really hone that habit of "continuous improvement")

                  In my other parlance here, we use "bridging strategies", while we are at the "Scrum on the march" stage, and until we can get to the "Full On Scrum" stage of maturity.
                   
                  -------
                  Charles Bradley
                  Professional Scrum Trainer
                  Scrum Coach-in-Chief
                  ScrumCrazy.com




                  From: Markus Gaertner <mgaertne@...>
                  To: scrumdevelopment@yahoogroups.com
                  Sent: Wednesday, September 11, 2013 4:05 AM
                  Subject: Re: [scrumdevelopment] Potentially Releasable Increment



                  Depending on the state of the development, #1 is usually hard for them when they get started with Scrum. That said, when starting with Scrum the "push of a button release" is usually an ideal, that needs to be addressed over time once the team starts to get over the "getting familiar with Scrum" hump of pain towards the "let's start improving things" stage of team building. At that point, I would expect the team to expand their Definition of Done to the degree that "push of a button release" becomes more realistic.

                  That said, I think #1 and #2 play together with each other in your model.

                  Best
                  Markus


                  On Wed, Sep 11, 2013 at 11: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?

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







                  --
                  Dipl.-Inform. Markus Gaertner
                  Author of ATDD by Example - A Practical Guide to Acceptance Test-Driven Development




                • Charles Bradley - Professional Scrum Trai
                  Ron, Good stuff as usual.  I especially appreciate your reference to the Scrum Guide. Re: #3 ... optional aspect of the DoD, it seems to me. Therefore it
                  Message 8 of 14 , Sep 20, 2013
                  • 0 Attachment
                    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





                  • Charles Bradley - Professional Scrum Trai
                    Tim, ... feature gap. However, they knew they could build that feature by the time it was actually needed by the business. While I agree with you that is a
                    Message 9 of 14 , Sep 20, 2013
                    • 0 Attachment
                      Tim,

                      > They went live without any "monthly statement" feature. That's a clear
                      feature gap. However, they knew they could build that feature by the time it was actually needed by the business.

                      While I agree with you that is a "clear feature gap," it's apparently not one that would 'cause any material amount of "product goodwill" to be lost by users' -- so it still complies with #3 as far as I'm concerned.

                      But you have me thinking.. maybe a little re-wording like...

                      > No "horrible feature gaps^1" that would cause any material amount of "product goodwill" to be lost by users
                      rewritten as:
                      > No "embarrassing/horrible feature gaps^1 or defects" that would cause an unacceptable amount of "product goodwill" or value to be lost by users.


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




                      From: Tim Wright <tim@...>
                      To: scrumdevelopment@yahoogroups.com
                      Sent: Wednesday, September 11, 2013 4:11 AM
                      Subject: Re: [scrumdevelopment] Potentially Releasable Increment



                      I'm not sure I entirely agree with #3. 

                      For example, I heard about a project team making an ordering/invoicing system. They went live without any "monthly statement" feature. That's a clear feature gap. However, they knew they could build that feature by the time it was actually needed by the business.

                      (this is potentially a "friend of a friend" type story - but even if it's not real, it illustrates the point quite nicely :)

                      Tim


                      On 11 September 2013 22:05, Markus Gaertner <mgaertne@...> wrote:
                       
                      Depending on the state of the development, #1 is usually hard for them when they get started with Scrum. That said, when starting with Scrum the "push of a button release" is usually an ideal, that needs to be addressed over time once the team starts to get over the "getting familiar with Scrum" hump of pain towards the "let's start improving things" stage of team building. At that point, I would expect the team to expand their Definition of Done to the degree that "push of a button release" becomes more realistic.

                      That said, I think #1 and #2 play together with each other in your model.

                      Best
                      Markus


                      On Wed, Sep 11, 2013 at 11: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?

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







                      --
                      Dipl.-Inform. Markus Gaertner
                      Author of ATDD by Example - A Practical Guide to Acceptance Test-Driven Development



                      --
                      Tim
                      021 251 5593




                    • Adam Sroka
                      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
                      Message 10 of 14 , Sep 20, 2013
                      • 0 Attachment
                        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






                      • Charles Bradley - Professional Scrum Trai
                        ... 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
                        Message 11 of 14 , Sep 20, 2013
                        • 0 Attachment
                          > 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
                          #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 12 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 13 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 14 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.