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

Re: [scrumdevelopment] Potentially Releasable Increment

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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.