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

[agile-usability] What's your definition of done?

Expand Messages
  • Justin Tauber
    Hi all, I ve been lurking for a while... absolutely love this list, though I am very much a newbie to agile. The list has been very quiet lately, so
    Message 1 of 20 , Aug 16, 2011
      Hi all,

      <preamble>
      I've been lurking for a while... absolutely love this list, though I am very much a newbie to agile. The list has been very quiet lately, so glad to see it alive again.
      I'm an experience architect at a digital agency that doesn't currently do any agile, but I am slowly getting myself in a position to introduce it.
      </preamble>

      There's been a lot of talk lately about adding things to teams' definitions of "done".

      I'd wager that concerns about defining done (dimly recognized perhaps) are what often drive people back into traditional waterfall models - i.e. specs are a way of defining "done" in an enforceable way (albeit usually at the expense of "doable" or "valuable")

      But I must admit I don't know what such a definition looks like.

      Anyone care to share their current working definitions...?

      Justin
    • Jon Kern
      Ask the customer what done is... More importantly is the reason why you should care about knowing what done means... jon blog: http://technicaldebt.com
      Message 2 of 20 , Aug 16, 2011
        Ask the customer what "done" is...

        More importantly is the reason why you should care about knowing what
        "done" means...

        jon

        blog: http://technicaldebt.com
        twitter: http://twitter.com/JonKernPA


        Justin Tauber said the following on 8/16/11 5:54 AM:
        >
        > Hi all,
        >
        > <preamble>
        > I've been lurking for a while... absolutely love this list, though I
        > am very much a newbie to agile. The list has been very quiet lately,
        > so glad to see it alive again.
        > I'm an experience architect at a digital agency that doesn't currently
        > do any agile, but I am slowly getting myself in a position to
        > introduce it.
        > </preamble>
        >
        > There's been a lot of talk lately about adding things to teams'
        > definitions of "done".
        >
        > I'd wager that concerns about defining done (dimly recognized perhaps)
        > are what often drive people back into traditional waterfall models -
        > i.e. specs are a way of defining "done" in an enforceable way (albeit
        > usually at the expense of "doable" or "valuable")
        >
        > But I must admit I don't know what such a definition looks like.
        >
        > Anyone care to share their current working definitions...?
        >
        > Justin
        >
        >
      • Jeff Wall
        You can have a Definition of Done based upon what the customer wants/needs. But our Definition of Done is internal, and the customer never sees it. It is all
        Message 3 of 20 , Aug 16, 2011
          You can have a Definition of Done based upon what the customer wants/needs.  But our Definition of Done is internal, and the customer never sees it.  It is all about quality/standards/builds/deploys that kind of stuff.

          As an example, is an Iteration complete when the develop is done coding?  Our Definition of Done says an iteration is complete when every story has a complete set of unit tests, each story has a complete set of QA test scripts positive and negative, UI standards/guidelines have been adhered to (eg. you can't have inconsistent button placement or garbage on the screen and be "Done")

          Our Definition of Done is very simple.  We wrote done 6-8 items on a large poster size post-it note and stuck it on the wall.  It has lines, boxes, exclamation points, arrows....it is very crude but there is no question about what everything means.  When the iteration ends on Tuesday, these items must be done.

          Jeff


          On Tue, Aug 16, 2011 at 9:18 AM, Jon Kern <jonkern@...> wrote:
          Ask the customer what "done" is...

          More importantly is the reason why you should care about knowing what
          "done" means...

          jon

          blog: http://technicaldebt.com
          twitter: http://twitter.com/JonKernPA


          Justin Tauber said the following on 8/16/11 5:54 AM:
          >
          > Hi all,
          >
          > <preamble>
          > I've been lurking for a while... absolutely love this list, though I
          > am very much a newbie to agile. The list has been very quiet lately,
          > so glad to see it alive again.
          > I'm an experience architect at a digital agency that doesn't currently
          > do any agile, but I am slowly getting myself in a position to
          > introduce it.
          > </preamble>
          >
          > There's been a lot of talk lately about adding things to teams'
          > definitions of "done".
          >
          > I'd wager that concerns about defining done (dimly recognized perhaps)
          > are what often drive people back into traditional waterfall models -
          > i.e. specs are a way of defining "done" in an enforceable way (albeit
          > usually at the expense of "doable" or "valuable")
          >
          > But I must admit I don't know what such a definition looks like.
          >
          > Anyone care to share their current working definitions...?
          >
          > Justin
          >
          >


          ------------------------------------

          Yahoo! Groups Links

          <*> To visit your group on the web, go to:
             http://groups.yahoo.com/group/agile-usability/

          <*> Your email settings:
             Individual Email | Traditional

          <*> To change settings online go to:
             http://groups.yahoo.com/group/agile-usability/join
             (Yahoo! ID required)

          <*> To change settings via email:
             agile-usability-digest@yahoogroups.com
             agile-usability-fullfeatured@yahoogroups.com

          <*> To unsubscribe from this group, send an email to:
             agile-usability-unsubscribe@yahoogroups.com

          <*> Your use of Yahoo! Groups is subject to:
             http://docs.yahoo.com/info/terms/




          --
          Jeffrey M. Wall
          Sr. Business Systems Analyst
          919.355.8312
          jmwall67@...
        • Joshua Kerievsky
          ... I blogged about the Definition of Done here: http://bit.ly/9KrweH -- best, jk -- Joshua Kerievsky Founder, CEO Industrial Logic, Inc. Web:
          Message 4 of 20 , Aug 16, 2011
            On Tue, Aug 16, 2011 at 2:54 AM, Justin Tauber <anotherjustin@...> wrote:
            Anyone care to share their current working definitions...?

            I blogged about the Definition of Done here: http://bit.ly/9KrweH

            -- 
            best,
            jk

            --
            Joshua Kerievsky
            Founder, CEO
            Industrial Logic, Inc.
            Web: http://industriallogic.com
            Twitter: @JoshuaKerievsky, @IndustrialLogic

            Amplify Your Agility
            Coaching | Training | Assessment | eLearning
          • Adrian Howard
            Hi Justin, ... [snip] My preferred definition of done is: When everybody on the team agrees that the story is done I m not trying to avoid the question -
            Message 5 of 20 , Aug 17, 2011
              Hi Justin,

              On 16 Aug 2011, at 10:54, Justin Tauber wrote:

              > I'd wager that concerns about defining done (dimly recognized perhaps) are
              > what often drive people back into traditional waterfall models - i.e. specs
              > are a way of defining "done" in an enforceable way (albeit usually at the
              > expense of "doable" or "valuable")
              >
              > But I must admit I don't know what such a definition looks like.
              >
              > Anyone care to share their current working definitions...?
              [snip]

              My preferred definition of done is:

              When everybody on the team agrees that the story is done

              I'm not trying to avoid the question - honest ;-)

              To me it implies:

              1) the team includes all the people needed to define what "done" is - including customer/user/stakeholder (proxies if necessary)

              2) the team has to agree

              "Done" is not a document. It's the values held by the team applied to the story that they're working on in the context they are working in.

              For example story Foo is about some quick learning about whether the customers are interested in a feature. So we're happy to deploy it to a small percentage of the users for a couple of days with less design polish than we would normally apply to a final feature. "Done" for that story would be the answer to the question that we released the feature to discover.

              For a context that has continuous deployment then the definition of "done" might include it being in the hands of the majority of the users of the system for a week without problems.

              One place I worked included "Getting an e-mail from both MDs that the feature was okay after it had been demoed to them" (since they were rarely onsite together, and often virulently disagreed over whether something was okay or not... which was a separate problem :-)

              Now their might be a list of a few things on the wall that act as a reminder for some stuff that we occasionally forget, or as a statement of our values. But the definition of "done" lives in the teams heads.

              Cheers,

              Adrian
              --
              http://quietstars.com adrianh@... twitter.com/adrianh
              t. +44 (0)7752 419080 skype adrianjohnhoward del.icio.us/adrianh
            • Jeremy Kriegel
              There are a lot of components to done, coded, tested, etc. As a UX practitioner, I ll focus on the quality aspect as it relates to our work. Based on the
              Message 6 of 20 , Aug 17, 2011
                There are a lot of components to done, coded, tested, etc. As a UX practitioner, I'll focus on the quality aspect as it relates to our work.

                Based on the conversation here, you could break the definition of done into 2 parts, releasable & acceptable. 

                Releasable
                This refers to when has the story been developed enough that it can be released into the wild. This goes beyond minimally marketable to minimally useful. If the goal it to see if users will be interested in a feature, what is the minimal functionality and usability to give it a shot at success? I'm sure you've looked at newly launched sites before and thought, "interesting idea, but just not there." They may have had a minimally marketable feature set, it did get your attention, but it wasn't minimally useful, at least not to you. 

                The level of quality can vary greatly as well. Releasing a new feature that is a critical part of the product that users will interact with regularly may require a higher bar than a threshold feature, one that must be present to meet expectations, but won't delight the user or be used regularly. For example, the registration process might get more attention than the change mailing address feature.

                Acceptable
                As many have pointed out, this goes beyond the development in an individual iteration to the level of customer acceptance or, dare I say, delight. This may require a different level of quality than the initial release. What is the minimal level of quality acceptable to release to world may be below the ultimate quality goal for the feature or interaction. Understanding how target users react to what was built and comparing that with the quality goal will help determine when the team is 'done' iterating on that feature, at least for the short term.

                Ownership
                At least in scrum, the product owner is the final decision maker. The developers advocate for code quality and warn if too much technical debt is being incurred. The UX practitioner advocates for the design quality and warns if the design may not meet expectations. Marketing will push for release dates to be fast and other stakeholders will have their needs as well. It is up to the product owner to make the final call. 

                Explicit Communication
                Good communication enhances agility. The more you can define what done means, the more likely you are to be able to achieve it. If the understanding is implicit, you run the risk that the expectations of the team are not aligned.

                While this might sound easy, it is not. I've worked with many teams, all of whom have done well at parts of this, but none who have gotten the whole process down. Agile is an evolution. Try to be better today than you were yesterday.

                -jer


                "Be well, do good work & keep in touch."
                     - Garrison Keillor


                On Wed, Aug 17, 2011 at 4:39 AM, Adrian Howard <adrianh@...> wrote:
                 

                Hi Justin,



                On 16 Aug 2011, at 10:54, Justin Tauber wrote:

                > I'd wager that concerns about defining done (dimly recognized perhaps) are
                > what often drive people back into traditional waterfall models - i.e. specs
                > are a way of defining "done" in an enforceable way (albeit usually at the
                > expense of "doable" or "valuable")
                >
                > But I must admit I don't know what such a definition looks like.
                >
                > Anyone care to share their current working definitions...?
                [snip]

                My preferred definition of done is:

                When everybody on the team agrees that the story is done

                I'm not trying to avoid the question - honest ;-)

                To me it implies:

                1) the team includes all the people needed to define what "done" is - including customer/user/stakeholder (proxies if necessary)

                2) the team has to agree

                "Done" is not a document. It's the values held by the team applied to the story that they're working on in the context they are working in.

                For example story Foo is about some quick learning about whether the customers are interested in a feature. So we're happy to deploy it to a small percentage of the users for a couple of days with less design polish than we would normally apply to a final feature. "Done" for that story would be the answer to the question that we released the feature to discover.

                For a context that has continuous deployment then the definition of "done" might include it being in the hands of the majority of the users of the system for a week without problems.

                One place I worked included "Getting an e-mail from both MDs that the feature was okay after it had been demoed to them" (since they were rarely onsite together, and often virulently disagreed over whether something was okay or not... which was a separate problem :-)

                Now their might be a list of a few things on the wall that act as a reminder for some stuff that we occasionally forget, or as a statement of our values. But the definition of "done" lives in the teams heads.

                Cheers,

                Adrian
                --
                http://quietstars.com adrianh@... twitter.com/adrianh
                t. +44 (0)7752 419080 skype adrianjohnhoward del.icio.us/adrianh


              • Gene Arch
                I must respectfully disagree with you, Adrian. The definition you espouse seems to take the work outside of the iteration, which to me seems to make it harder
                Message 7 of 20 , Aug 17, 2011
                  I must respectfully disagree with you, Adrian.  The definition you espouse seems to take the work outside of the iteration, which to me seems to make it harder to really nail down what done is.  Your definition given below seems to lend itself to stories hanging out there without a definite resolution, which makes it difficult to show progress.  For instance, in your example of the MDs agreeing on a feature being ok, what did you do in the event they disagreed?  Did a story sit out there until they could reconcile their differences?  Wouldn't it be better to agree upon what is acceptable relative to what you understand were the requirements from the MDs, and if they can't agree on whether or not the feature is acceptable, then that's an issue outside the development iteration.  Something that, as you stated, is a separate problem.  
                   
                  I have difficulty with anything living "inside the team's heads," because when it does, it is often subject to misinterpretation and hidden assumptions.  If the team documents their definition of done in a tangible manner and keeps it close, then in the event of disagreements during an iteration, they can bring it out and point to it as a reference point for the discussion.  I'm not saying the definition is the end-all be-all (it necessarily should be reviewed on a regular basis and updated based on new information), but to leave it to the team's individual assumptions seems dangerous to me.
                   
                  I may be misunderstanding you, and if so, I apologize.  I am also a relatively new practitioner of agile, so I could be off my rocker as well, but this is how I understand it.
                   
                  Respectfully,
                  ~Gene 
                   
                   

                  From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Adrian Howard
                  Sent: Wednesday, August 17, 2011 3:40 AM
                  To: agile-usability@yahoogroups.com
                  Subject: Re: [agile-usability] What's your definition of done?

                   

                  Hi Justin,

                  On 16 Aug 2011, at 10:54, Justin Tauber wrote:

                  > I'd wager that concerns about defining done (dimly recognized perhaps) are
                  > what often drive people back into traditional waterfall models - i.e. specs
                  > are a way of defining "done" in an enforceable way (albeit usually at the
                  > expense of "doable" or "valuable")
                  >
                  > But I must admit I don't know what such a definition looks like.
                  >
                  > Anyone care to share their current working definitions...?
                  [snip]

                  My preferred definition of done is:

                  When everybody on the team agrees that the story is done

                  I'm not trying to avoid the question - honest ;-)

                  To me it implies:

                  1) the team includes all the people needed to define what "done" is - including customer/user/stakeholder (proxies if necessary)

                  2) the team has to agree

                  "Done" is not a document. It's the values held by the team applied to the story that they're working on in the context they are working in.

                  For example story Foo is about some quick learning about whether the customers are interested in a feature. So we're happy to deploy it to a small percentage of the users for a couple of days with less design polish than we would normally apply to a final feature. "Done" for that story would be the answer to the question that we released the feature to discover.

                  For a context that has continuous deployment then the definition of "done" might include it being in the hands of the majority of the users of the system for a week without problems.

                  One place I worked included "Getting an e-mail from both MDs that the feature was okay after it had been demoed to them" (since they were rarely onsite together, and often virulently disagreed over whether something was okay or not... which was a separate problem :-)

                  Now their might be a list of a few things on the wall that act as a reminder for some stuff that we occasionally forget, or as a statement of our values. But the definition of "done" lives in the teams heads.

                  Cheers,

                  Adrian
                  --
                  http://quietstars.com adrianh@... twitter.com/adrianh
                  t. +44 (0)7752 419080 skype adrianjohnhoward del.icio.us/adrianh

                • Anders Ramsay
                  There is no one correct definition of a story being Done. Anyone looking for that definition has misunderstood what Done is about. Done is a judgment call
                  Message 8 of 20 , Aug 17, 2011

                    There is no one correct definition of a story being Done.  Anyone looking for that definition has misunderstood what Done is about. 

                    Done is a judgment call made in a particular moment and based on the idiosyncrasies of a particular situation. It is often a very difficult choice.

                    Done is *not* about some feature being delivered in glorious perfection. Few are.

                    Done is a tool for helping teams make decisions and be able to move forward.


                    On Wed, Aug 17, 2011 at 9:33 AM, Gene Arch <garch@...> wrote:
                     

                    I must respectfully disagree with you, Adrian.  The definition you espouse seems to take the work outside of the iteration, which to me seems to make it harder to really nail down what done is.  Your definition given below seems to lend itself to stories hanging out there without a definite resolution, which makes it difficult to show progress.  For instance, in your example of the MDs agreeing on a feature being ok, what did you do in the event they disagreed?  Did a story sit out there until they could reconcile their differences?  Wouldn't it be better to agree upon what is acceptable relative to what you understand were the requirements from the MDs, and if they can't agree on whether or not the feature is acceptable, then that's an issue outside the development iteration.  Something that, as you stated, is a separate problem.  
                     
                    I have difficulty with anything living "inside the team's heads," because when it does, it is often subject to misinterpretation and hidden assumptions.  If the team documents their definition of done in a tangible manner and keeps it close, then in the event of disagreements during an iteration, they can bring it out and point to it as a reference point for the discussion.  I'm not saying the definition is the end-all be-all (it necessarily should be reviewed on a regular basis and updated based on new information), but to leave it to the team's individual assumptions seems dangerous to me.
                     
                    I may be misunderstanding you, and if so, I apologize.  I am also a relatively new practitioner of agile, so I could be off my rocker as well, but this is how I understand it.
                     
                    Respectfully,
                    ~Gene 
                     
                     

                    From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Adrian Howard
                    Sent: Wednesday, August 17, 2011 3:40 AM
                    To: agile-usability@yahoogroups.com
                    Subject: Re: [agile-usability] What's your definition of done?

                     

                    Hi Justin,

                    On 16 Aug 2011, at 10:54, Justin Tauber wrote:

                    > I'd wager that concerns about defining done (dimly recognized perhaps) are
                    > what often drive people back into traditional waterfall models - i.e. specs
                    > are a way of defining "done" in an enforceable way (albeit usually at the
                    > expense of "doable" or "valuable")
                    >
                    > But I must admit I don't know what such a definition looks like.
                    >
                    > Anyone care to share their current working definitions...?
                    [snip]

                    My preferred definition of done is:

                    When everybody on the team agrees that the story is done

                    I'm not trying to avoid the question - honest ;-)

                    To me it implies:

                    1) the team includes all the people needed to define what "done" is - including customer/user/stakeholder (proxies if necessary)

                    2) the team has to agree

                    "Done" is not a document. It's the values held by the team applied to the story that they're working on in the context they are working in.

                    For example story Foo is about some quick learning about whether the customers are interested in a feature. So we're happy to deploy it to a small percentage of the users for a couple of days with less design polish than we would normally apply to a final feature. "Done" for that story would be the answer to the question that we released the feature to discover.

                    For a context that has continuous deployment then the definition of "done" might include it being in the hands of the majority of the users of the system for a week without problems.

                    One place I worked included "Getting an e-mail from both MDs that the feature was okay after it had been demoed to them" (since they were rarely onsite together, and often virulently disagreed over whether something was okay or not... which was a separate problem :-)

                    Now their might be a list of a few things on the wall that act as a reminder for some stuff that we occasionally forget, or as a statement of our values. But the definition of "done" lives in the teams heads.

                    Cheers,

                    Adrian
                    --
                    http://quietstars.com adrianh@... twitter.com/adrianh
                    t. +44 (0)7752 419080 skype adrianjohnhoward del.icio.us/adrianh


                  • Jeremy Kriegel
                    ... for that definition has misunderstood what Done is about. Agree to an extent. It changes based on the story. However, there are characteristics of done.
                    Message 9 of 20 , Aug 17, 2011
                      >>There is no one correct definition of a story being Done.  Anyone looking for that definition has misunderstood what Done is about.

                      Agree to an extent. It changes based on the story. However, there are characteristics of done.

                      >>Done is a judgment call made in a particular moment and based on the idiosyncrasies of a particular situation. It is often a very difficult choice.

                      In practice, this is often the case, but if the team doesn't have a shared understanding of what they are aiming for, you are unlikely to be happy with the results.

                      >>Done is *not* about some feature being delivered in glorious perfection. Few are.
                      >>Done is a tool for helping teams make decisions and be able to move forward.

                      Completely agree.
                       
                      -jer

                      "Be well, do good work & keep in touch."
                           - Garrison Keillor


                      On Wed, Aug 17, 2011 at 10:07 AM, Anders Ramsay <andersr@...> wrote:
                       

                      There is no one correct definition of a story being Done.  Anyone looking for that definition has misunderstood what Done is about. 

                      Done is a judgment call made in a particular moment and based on the idiosyncrasies of a particular situation. It is often a very difficult choice.

                      Done is *not* about some feature being delivered in glorious perfection. Few are.

                      Done is a tool for helping teams make decisions and be able to move forward.


                      On Wed, Aug 17, 2011 at 9:33 AM, Gene Arch <garch@...> wrote:
                       

                      I must respectfully disagree with you, Adrian.  The definition you espouse seems to take the work outside of the iteration, which to me seems to make it harder to really nail down what done is.  Your definition given below seems to lend itself to stories hanging out there without a definite resolution, which makes it difficult to show progress.  For instance, in your example of the MDs agreeing on a feature being ok, what did you do in the event they disagreed?  Did a story sit out there until they could reconcile their differences?  Wouldn't it be better to agree upon what is acceptable relative to what you understand were the requirements from the MDs, and if they can't agree on whether or not the feature is acceptable, then that's an issue outside the development iteration.  Something that, as you stated, is a separate problem.  
                       
                      I have difficulty with anything living "inside the team's heads," because when it does, it is often subject to misinterpretation and hidden assumptions.  If the team documents their definition of done in a tangible manner and keeps it close, then in the event of disagreements during an iteration, they can bring it out and point to it as a reference point for the discussion.  I'm not saying the definition is the end-all be-all (it necessarily should be reviewed on a regular basis and updated based on new information), but to leave it to the team's individual assumptions seems dangerous to me.
                       
                      I may be misunderstanding you, and if so, I apologize.  I am also a relatively new practitioner of agile, so I could be off my rocker as well, but this is how I understand it.
                       
                      Respectfully,
                      ~Gene 
                       
                       

                      From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Adrian Howard
                      Sent: Wednesday, August 17, 2011 3:40 AM
                      To: agile-usability@yahoogroups.com
                      Subject: Re: [agile-usability] What's your definition of done?

                       

                      Hi Justin,

                      On 16 Aug 2011, at 10:54, Justin Tauber wrote:

                      > I'd wager that concerns about defining done (dimly recognized perhaps) are
                      > what often drive people back into traditional waterfall models - i.e. specs
                      > are a way of defining "done" in an enforceable way (albeit usually at the
                      > expense of "doable" or "valuable")
                      >
                      > But I must admit I don't know what such a definition looks like.
                      >
                      > Anyone care to share their current working definitions...?
                      [snip]

                      My preferred definition of done is:

                      When everybody on the team agrees that the story is done

                      I'm not trying to avoid the question - honest ;-)

                      To me it implies:

                      1) the team includes all the people needed to define what "done" is - including customer/user/stakeholder (proxies if necessary)

                      2) the team has to agree

                      "Done" is not a document. It's the values held by the team applied to the story that they're working on in the context they are working in.

                      For example story Foo is about some quick learning about whether the customers are interested in a feature. So we're happy to deploy it to a small percentage of the users for a couple of days with less design polish than we would normally apply to a final feature. "Done" for that story would be the answer to the question that we released the feature to discover.

                      For a context that has continuous deployment then the definition of "done" might include it being in the hands of the majority of the users of the system for a week without problems.

                      One place I worked included "Getting an e-mail from both MDs that the feature was okay after it had been demoed to them" (since they were rarely onsite together, and often virulently disagreed over whether something was okay or not... which was a separate problem :-)

                      Now their might be a list of a few things on the wall that act as a reminder for some stuff that we occasionally forget, or as a statement of our values. But the definition of "done" lives in the teams heads.

                      Cheers,

                      Adrian
                      --
                      http://quietstars.com adrianh@... twitter.com/adrianh
                      t. +44 (0)7752 419080 skype adrianjohnhoward del.icio.us/adrianh



                    • Michael James
                      I agree there s no one definition that works for all teams. Teams and POs have to work together to find the right one for their products. The discussion is
                      Message 10 of 20 , Aug 17, 2011
                        I agree there's no one definition that works for all teams.  Teams and POs have to work together to find the right one for their products.  The discussion is usually longer overdue.  

                        As a starting point in the discussion, I usually suggest "properly tested, refactored (e.g. duplicate code removed), and potentially shippable."  I don't mean that as a definition as much as a starting point to fruitful discussions.

                        --mj


                        On Aug 17, 2011, at 7:07 AM, Anders Ramsay <andersr@...> wrote:

                         

                        There is no one correct definition of a story being Done.  Anyone looking for that definition has misunderstood what Done is about. 

                        Done is a judgment call made in a particular moment and based on the idiosyncrasies of a particular situation. It is often a very difficult choice.

                        Done is *not* about some feature being delivered in glorious perfection. Few are.

                        Done is a tool for helping teams make decisions and be able to move forward.


                        On Wed, Aug 17, 2011 at 9:33 AM, Gene Arch <garch@...> wrote:
                         

                        I must respectfully disagree with you, Adrian.  The definition you espouse seems to take the work outside of the iteration, which to me seems to make it harder to really nail down what done is.  Your definition given below seems to lend itself to stories hanging out there without a definite resolution, which makes it difficult to show progress.  For instance, in your example of the MDs agreeing on a feature being ok, what did you do in the event they disagreed?  Did a story sit out there until they could reconcile their differences?  Wouldn't it be better to agree upon what is acceptable relative to what you understand were the requirements from the MDs, and if they can't agree on whether or not the feature is acceptable, then that's an issue outside the development iteration.  Something that, as you stated, is a separate problem.  
                         
                        I have difficulty with anything living "inside the team's heads," because when it does, it is often subject to misinterpretation and hidden assumptions.  If the team documents their definition of done in a tangible manner and keeps it close, then in the event of disagreements during an iteration, they can bring it out and point to it as a reference point for the discussion.  I'm not saying the definition is the end-all be-all (it necessarily should be reviewed on a regular basis and updated based on new information), but to leave it to the team's individual assumptions seems dangerous to me.
                         
                        I may be misunderstanding you, and if so, I apologize.  I am also a relatively new practitioner of agile, so I could be off my rocker as well, but this is how I understand it.
                         
                        Respectfully,
                        ~Gene 
                         
                         

                        From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Adrian Howard
                        Sent: Wednesday, August 17, 2011 3:40 AM
                        To: agile-usability@yahoogroups.com
                        Subject: Re: [agile-usability] What's your definition of done?

                         

                        Hi Justin,

                        On 16 Aug 2011, at 10:54, Justin Tauber wrote:

                        > I'd wager that concerns about defining done (dimly recognized perhaps) are
                        > what often drive people back into traditional waterfall models - i.e. specs
                        > are a way of defining "done" in an enforceable way (albeit usually at the
                        > expense of "doable" or "valuable")
                        >
                        > But I must admit I don't know what such a definition looks like.
                        >
                        > Anyone care to share their current working definitions...?
                        [snip]

                        My preferred definition of done is:

                        When everybody on the team agrees that the story is done

                        I'm not trying to avoid the question - honest ;-)

                        To me it implies:

                        1) the team includes all the people needed to define what "done" is - including customer/user/stakeholder (proxies if necessary)

                        2) the team has to agree

                        "Done" is not a document. It's the values held by the team applied to the story that they're working on in the context they are working in.

                        For example story Foo is about some quick learning about whether the customers are interested in a feature. So we're happy to deploy it to a small percentage of the users for a couple of days with less design polish than we would normally apply to a final feature. "Done" for that story would be the answer to the question that we released the feature to discover.

                        For a context that has continuous deployment then the definition of "done" might include it being in the hands of the majority of the users of the system for a week without problems.

                        One place I worked included "Getting an e-mail from both MDs that the feature was okay after it had been demoed to them" (since they were rarely onsite together, and often virulently disagreed over whether something was okay or not... which was a separate problem :-)

                        Now their might be a list of a few things on the wall that act as a reminder for some stuff that we occasionally forget, or as a statement of our values. But the definition of "done" lives in the teams heads.

                        Cheers,

                        Adrian
                        --
                        http://quietstars.com adrianh@... twitter.com/adrianh
                        t. +44 (0)7752 419080 skype adrianjohnhoward del.icio.us/adrianh


                      • Gene Arch
                        I agree with both of you - the team must agree on what is done, and every team s definition will be different. I was mainly concerned about that definition
                        Message 11 of 20 , Aug 17, 2011
                          I agree with both of you - the team must agree on what is "done," and every team's definition will be different.  I was mainly concerned about that definition living "in the heads" of the team, rather than explicitly stated and agreed upon.
                           
                          >>Done is a tool for helping teams make decisions and be able to move forward.
                           
                          Bears repeating.  It's exactly what I meant - teams need a reference point with which to make the difficult day-to-day decisions about priority and scope. "Done" and the Project Charter are both great tools to help with that.
                           
                          ~Gene


                          From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Jeremy Kriegel
                          Sent: Wednesday, August 17, 2011 9:37 AM
                          To: agile-usability@yahoogroups.com
                          Subject: Re: [agile-usability] What's your definition of done?

                           

                          >>There is no one correct definition of a story being Done.  Anyone looking for that definition has misunderstood what Done is about.


                          Agree to an extent. It changes based on the story. However, there are characteristics of done.

                          >>Done is a judgment call made in a particular moment and based on the idiosyncrasies of a particular situation. It is often a very difficult choice.

                          In practice, this is often the case, but if the team doesn't have a shared understanding of what they are aiming for, you are unlikely to be happy with the results.

                          >>Done is *not* about some feature being delivered in glorious perfection. Few are.
                          >>Done is a tool for helping teams make decisions and be able to move forward.

                          Completely agree.
                           
                          -jer

                          "Be well, do good work & keep in touch."
                               - Garrison Keillor


                          On Wed, Aug 17, 2011 at 10:07 AM, Anders Ramsay <andersr@...> wrote:
                           

                          There is no one correct definition of a story being Done.  Anyone looking for that definition has misunderstood what Done is about. 

                          Done is a judgment call made in a particular moment and based on the idiosyncrasies of a particular situation. It is often a very difficult choice.

                          Done is *not* about some feature being delivered in glorious perfection. Few are.

                          Done is a tool for helping teams make decisions and be able to move forward.


                          On Wed, Aug 17, 2011 at 9:33 AM, Gene Arch <garch@...> wrote:
                           

                          I must respectfully disagree with you, Adrian.  The definition you espouse seems to take the work outside of the iteration, which to me seems to make it harder to really nail down what done is.  Your definition given below seems to lend itself to stories hanging out there without a definite resolution, which makes it difficult to show progress.  For instance, in your example of the MDs agreeing on a feature being ok, what did you do in the event they disagreed?  Did a story sit out there until they could reconcile their differences?  Wouldn't it be better to agree upon what is acceptable relative to what you understand were the requirements from the MDs, and if they can't agree on whether or not the feature is acceptable, then that's an issue outside the development iteration.  Something that, as you stated, is a separate problem.  
                           
                          I have difficulty with anything living "inside the team's heads," because when it does, it is often subject to misinterpretation and hidden assumptions.  If the team documents their definition of done in a tangible manner and keeps it close, then in the event of disagreements during an iteration, they can bring it out and point to it as a reference point for the discussion.  I'm not saying the definition is the end-all be-all (it necessarily should be reviewed on a regular basis and updated based on new information), but to leave it to the team's individual assumptions seems dangerous to me.
                           
                          I may be misunderstanding you, and if so, I apologize.  I am also a relatively new practitioner of agile, so I could be off my rocker as well, but this is how I understand it.
                           
                          Respectfully,
                          ~Gene 
                           
                           

                          From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Adrian Howard
                          Sent: Wednesday, August 17, 2011 3:40 AM
                          To: agile-usability@yahoogroups.com
                          Subject: Re: [agile-usability] What's your definition of done?

                           

                          Hi Justin,

                          On 16 Aug 2011, at 10:54, Justin Tauber wrote:

                          > I'd wager that concerns about defining done (dimly recognized perhaps) are
                          > what often drive people back into traditional waterfall models - i.e. specs
                          > are a way of defining "done" in an enforceable way (albeit usually at the
                          > expense of "doable" or "valuable")
                          >
                          > But I must admit I don't know what such a definition looks like.
                          >
                          > Anyone care to share their current working definitions...?
                          [snip]

                          My preferred definition of done is:

                          When everybody on the team agrees that the story is done

                          I'm not trying to avoid the question - honest ;-)

                          To me it implies:

                          1) the team includes all the people needed to define what "done" is - including customer/user/stakeholder (proxies if necessary)

                          2) the team has to agree

                          "Done" is not a document. It's the values held by the team applied to the story that they're working on in the context they are working in.

                          For example story Foo is about some quick learning about whether the customers are interested in a feature. So we're happy to deploy it to a small percentage of the users for a couple of days with less design polish than we would normally apply to a final feature. "Done" for that story would be the answer to the question that we released the feature to discover.

                          For a context that has continuous deployment then the definition of "done" might include it being in the hands of the majority of the users of the system for a week without problems.

                          One place I worked included "Getting an e-mail from both MDs that the feature was okay after it had been demoed to them" (since they were rarely onsite together, and often virulently disagreed over whether something was okay or not... which was a separate problem :-)

                          Now their might be a list of a few things on the wall that act as a reminder for some stuff that we occasionally forget, or as a statement of our values. But the definition of "done" lives in the teams heads.

                          Cheers,

                          Adrian
                          --
                          http://quietstars.com adrianh@... twitter.com/adrianh
                          t. +44 (0)7752 419080 skype adrianjohnhoward del.icio.us/adrianh



                        • Justin Tauber
                          Thanks for all the responses, they ve been really useful. I get the impressions that there a few different concepts that need unpacking here: * Done for an
                          Message 12 of 20 , Aug 17, 2011
                            Thanks for all the responses, they've been really useful.

                            I get the impressions that there a few different concepts that need unpacking here:
                            * Done for an iteration vs done for a release
                            * Done as an internal standard prior to exposure to customers vs done from the perspective of the customer 

                            Though I can see how from both an agile and a ux perspective there shouldn't be a standard that isn't end user focused, from a practical perspective it's hard to learn from usability tests run on buggy software, so some "internal" standards need to be adopted. From that perspective, Jeff's definition of done looks like meaning "ready to expose to usability testing". 

                            Which makes me wonder: is anyone working with a concept of "user debt" as a counterpart to "technical debt" ?

                            nb: It also seems to me that both "releasable" and "acceptable" as suggested earlier fall into the same side of the second inequality above. My hunch is that "Acceptable" - involving delighting the customer, might be very useful for game dev, but is probably rarely uses in a positive sense. You don't decide as a team that a feature / story has been perfected, you just never actually put it into another release scope. 

                            Justin Tauber
                            @brtrx

                            On 18/08/2011, at 1:26 AM, "Gene Arch" <garch@...> wrote:

                             

                            I agree with both of you - the team must agree on what is "done," and every team's definition will be different.  I was mainly concerned about that definition living "in the heads" of the team, rather than explicitly stated and agreed upon.
                             
                            >>Done is a tool for helping teams make decisions and be able to move forward.
                             
                            Bears repeating.  It's exactly what I meant - teams need a reference point with which to make the difficult day-to-day decisions about priority and scope. "Done" and the Project Charter are both great tools to help with that.
                             
                            ~Gene


                            From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Jeremy Kriegel
                            Sent: Wednesday, August 17, 2011 9:37 AM
                            To: agile-usability@yahoogroups.com
                            Subject: Re: [agile-usability] What's your definition of done?

                             

                            >>There is no one correct definition of a story being Done.  Anyone looking for that definition has misunderstood what Done is about.


                            Agree to an extent. It changes based on the story. However, there are characteristics of done.

                            >>Done is a judgment call made in a particular moment and based on the idiosyncrasies of a particular situation. It is often a very difficult choice.

                            In practice, this is often the case, but if the team doesn't have a shared understanding of what they are aiming for, you are unlikely to be happy with the results.

                            >>Done is *not* about some feature being delivered in glorious perfection. Few are.
                            >>Done is a tool for helping teams make decisions and be able to move forward.

                            Completely agree.
                             
                            -jer

                            "Be well, do good work & keep in touch."
                                 - Garrison Keillor


                            On Wed, Aug 17, 2011 at 10:07 AM, Anders Ramsay <andersr@...> wrote:
                             

                            There is no one correct definition of a story being Done.  Anyone looking for that definition has misunderstood what Done is about. 

                            Done is a judgment call made in a particular moment and based on the idiosyncrasies of a particular situation. It is often a very difficult choice.

                            Done is *not* about some feature being delivered in glorious perfection. Few are.

                            Done is a tool for helping teams make decisions and be able to move forward.


                            On Wed, Aug 17, 2011 at 9:33 AM, Gene Arch <garch@...> wrote:
                             

                            I must respectfully disagree with you, Adrian.  The definition you espouse seems to take the work outside of the iteration, which to me seems to make it harder to really nail down what done is.  Your definition given below seems to lend itself to stories hanging out there without a definite resolution, which makes it difficult to show progress.  For instance, in your example of the MDs agreeing on a feature being ok, what did you do in the event they disagreed?  Did a story sit out there until they could reconcile their differences?  Wouldn't it be better to agree upon what is acceptable relative to what you understand were the requirements from the MDs, and if they can't agree on whether or not the feature is acceptable, then that's an issue outside the development iteration.  Something that, as you stated, is a separate problem.  
                             
                            I have difficulty with anything living "inside the team's heads," because when it does, it is often subject to misinterpretation and hidden assumptions.  If the team documents their definition of done in a tangible manner and keeps it close, then in the event of disagreements during an iteration, they can bring it out and point to it as a reference point for the discussion.  I'm not saying the definition is the end-all be-all (it necessarily should be reviewed on a regular basis and updated based on new information), but to leave it to the team's individual assumptions seems dangerous to me.
                             
                            I may be misunderstanding you, and if so, I apologize.  I am also a relatively new practitioner of agile, so I could be off my rocker as well, but this is how I understand it.
                             
                            Respectfully,
                            ~Gene 
                             
                             

                            From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Adrian Howard
                            Sent: Wednesday, August 17, 2011 3:40 AM
                            To: agile-usability@yahoogroups.com
                            Subject: Re: [agile-usability] What's your definition of done?

                             

                            Hi Justin,

                            On 16 Aug 2011, at 10:54, Justin Tauber wrote:

                            > I'd wager that concerns about defining done (dimly recognized perhaps) are
                            > what often drive people back into traditional waterfall models - i.e. specs
                            > are a way of defining "done" in an enforceable way (albeit usually at the
                            > expense of "doable" or "valuable")
                            >
                            > But I must admit I don't know what such a definition looks like.
                            >
                            > Anyone care to share their current working definitions...?
                            [snip]

                            My preferred definition of done is:

                            When everybody on the team agrees that the story is done

                            I'm not trying to avoid the question - honest ;-)

                            To me it implies:

                            1) the team includes all the people needed to define what "done" is - including customer/user/stakeholder (proxies if necessary)

                            2) the team has to agree

                            "Done" is not a document. It's the values held by the team applied to the story that they're working on in the context they are working in.

                            For example story Foo is about some quick learning about whether the customers are interested in a feature. So we're happy to deploy it to a small percentage of the users for a couple of days with less design polish than we would normally apply to a final feature. "Done" for that story would be the answer to the question that we released the feature to discover.

                            For a context that has continuous deployment then the definition of "done" might include it being in the hands of the majority of the users of the system for a week without problems.

                            One place I worked included "Getting an e-mail from both MDs that the feature was okay after it had been demoed to them" (since they were rarely onsite together, and often virulently disagreed over whether something was okay or not... which was a separate problem :-)

                            Now their might be a list of a few things on the wall that act as a reminder for some stuff that we occasionally forget, or as a statement of our values. But the definition of "done" lives in the teams heads.

                            Cheers,

                            Adrian
                            --
                            http://quietstars.com adrianh@... twitter.com/adrianh
                            t. +44 (0)7752 419080 skype adrianjohnhoward del.icio.us/adrianh



                          • Anders Ramsay
                            ... I like the concept of user debt, as in we re indebted to the users :) UX debt is often a reference to a feature which technically functions as requested
                            Message 13 of 20 , Aug 17, 2011
                              On Wed, Aug 17, 2011 at 11:59 AM, Justin Tauber <anotherjustin@...> wrote:

                              Which makes me wonder: is anyone working with a concept of "user debt" as a counterpart to "technical debt" ? 
                               
                              I like the concept of "user debt," as in we're indebted to the users :) 

                              UX debt is often a reference to a feature which technically functions as requested but where the quality of the experience is low, e..g some stuff is not properly aligned, or the feel of the experience is clunky or whatever.

                              Defining something that has UX debt as Done means you'll be delivering a half-baked UX, which goes to the core of the UX field's complaint about Agile.

                              IMO, there should be no such thing as UX debt. Either the quality of the experience is appropriate for the product, context, and domain, or it is not.  (E.g. for an entertainment product, experience quality should likely be very high, for an enterprise product, this may be less critical.)

                              If a feature is seen as Done in every other way except for experience quality, then a decision can be made to call it Done and create a new card that addresses the particular experience quality issues and add it to the backlog.
                            • Jeremy Kriegel
                              There is absolutely user debt, design debt, usability debt, experience debt, or whatever. Just as compromises get made on the development that will hinder
                              Message 14 of 20 , Aug 17, 2011
                                There is absolutely user debt, design debt, usability debt, experience debt, or whatever. Just as compromises get made on the development that will hinder progress later, often similar compromises are made on the experience.

                                -jer

                                "Be well, do good work & keep in touch."
                                     - Garrison Keillor


                                On Wed, Aug 17, 2011 at 11:59 AM, Justin Tauber <anotherjustin@...> wrote:
                                 

                                Thanks for all the responses, they've been really useful.

                                I get the impressions that there a few different concepts that need unpacking here:
                                * Done for an iteration vs done for a release
                                * Done as an internal standard prior to exposure to customers vs done from the perspective of the customer 

                                Though I can see how from both an agile and a ux perspective there shouldn't be a standard that isn't end user focused, from a practical perspective it's hard to learn from usability tests run on buggy software, so some "internal" standards need to be adopted. From that perspective, Jeff's definition of done looks like meaning "ready to expose to usability testing". 

                                Which makes me wonder: is anyone working with a concept of "user debt" as a counterpart to "technical debt" ?

                                nb: It also seems to me that both "releasable" and "acceptable" as suggested earlier fall into the same side of the second inequality above. My hunch is that "Acceptable" - involving delighting the customer, might be very useful for game dev, but is probably rarely uses in a positive sense. You don't decide as a team that a feature / story has been perfected, you just never actually put it into another release scope. 

                                Justin Tauber
                                @brtrx

                                On 18/08/2011, at 1:26 AM, "Gene Arch" <garch@...> wrote:

                                 

                                I agree with both of you - the team must agree on what is "done," and every team's definition will be different.  I was mainly concerned about that definition living "in the heads" of the team, rather than explicitly stated and agreed upon.
                                 
                                >>Done is a tool for helping teams make decisions and be able to move forward.
                                 
                                Bears repeating.  It's exactly what I meant - teams need a reference point with which to make the difficult day-to-day decisions about priority and scope. "Done" and the Project Charter are both great tools to help with that.
                                 
                                ~Gene


                                From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Jeremy Kriegel
                                Sent: Wednesday, August 17, 2011 9:37 AM
                                To: agile-usability@yahoogroups.com
                                Subject: Re: [agile-usability] What's your definition of done?

                                 

                                >>There is no one correct definition of a story being Done.  Anyone looking for that definition has misunderstood what Done is about.


                                Agree to an extent. It changes based on the story. However, there are characteristics of done.

                                >>Done is a judgment call made in a particular moment and based on the idiosyncrasies of a particular situation. It is often a very difficult choice.

                                In practice, this is often the case, but if the team doesn't have a shared understanding of what they are aiming for, you are unlikely to be happy with the results.

                                >>Done is *not* about some feature being delivered in glorious perfection. Few are.
                                >>Done is a tool for helping teams make decisions and be able to move forward.

                                Completely agree.
                                 
                                -jer

                                "Be well, do good work & keep in touch."
                                     - Garrison Keillor


                                On Wed, Aug 17, 2011 at 10:07 AM, Anders Ramsay <andersr@...> wrote:
                                 

                                There is no one correct definition of a story being Done.  Anyone looking for that definition has misunderstood what Done is about. 

                                Done is a judgment call made in a particular moment and based on the idiosyncrasies of a particular situation. It is often a very difficult choice.

                                Done is *not* about some feature being delivered in glorious perfection. Few are.

                                Done is a tool for helping teams make decisions and be able to move forward.


                                On Wed, Aug 17, 2011 at 9:33 AM, Gene Arch <garch@...> wrote:
                                 

                                I must respectfully disagree with you, Adrian.  The definition you espouse seems to take the work outside of the iteration, which to me seems to make it harder to really nail down what done is.  Your definition given below seems to lend itself to stories hanging out there without a definite resolution, which makes it difficult to show progress.  For instance, in your example of the MDs agreeing on a feature being ok, what did you do in the event they disagreed?  Did a story sit out there until they could reconcile their differences?  Wouldn't it be better to agree upon what is acceptable relative to what you understand were the requirements from the MDs, and if they can't agree on whether or not the feature is acceptable, then that's an issue outside the development iteration.  Something that, as you stated, is a separate problem.  
                                 
                                I have difficulty with anything living "inside the team's heads," because when it does, it is often subject to misinterpretation and hidden assumptions.  If the team documents their definition of done in a tangible manner and keeps it close, then in the event of disagreements during an iteration, they can bring it out and point to it as a reference point for the discussion.  I'm not saying the definition is the end-all be-all (it necessarily should be reviewed on a regular basis and updated based on new information), but to leave it to the team's individual assumptions seems dangerous to me.
                                 
                                I may be misunderstanding you, and if so, I apologize.  I am also a relatively new practitioner of agile, so I could be off my rocker as well, but this is how I understand it.
                                 
                                Respectfully,
                                ~Gene 
                                 
                                 

                                From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Adrian Howard
                                Sent: Wednesday, August 17, 2011 3:40 AM
                                To: agile-usability@yahoogroups.com
                                Subject: Re: [agile-usability] What's your definition of done?

                                 

                                Hi Justin,

                                On 16 Aug 2011, at 10:54, Justin Tauber wrote:

                                > I'd wager that concerns about defining done (dimly recognized perhaps) are
                                > what often drive people back into traditional waterfall models - i.e. specs
                                > are a way of defining "done" in an enforceable way (albeit usually at the
                                > expense of "doable" or "valuable")
                                >
                                > But I must admit I don't know what such a definition looks like.
                                >
                                > Anyone care to share their current working definitions...?
                                [snip]

                                My preferred definition of done is:

                                When everybody on the team agrees that the story is done

                                I'm not trying to avoid the question - honest ;-)

                                To me it implies:

                                1) the team includes all the people needed to define what "done" is - including customer/user/stakeholder (proxies if necessary)

                                2) the team has to agree

                                "Done" is not a document. It's the values held by the team applied to the story that they're working on in the context they are working in.

                                For example story Foo is about some quick learning about whether the customers are interested in a feature. So we're happy to deploy it to a small percentage of the users for a couple of days with less design polish than we would normally apply to a final feature. "Done" for that story would be the answer to the question that we released the feature to discover.

                                For a context that has continuous deployment then the definition of "done" might include it being in the hands of the majority of the users of the system for a week without problems.

                                One place I worked included "Getting an e-mail from both MDs that the feature was okay after it had been demoed to them" (since they were rarely onsite together, and often virulently disagreed over whether something was okay or not... which was a separate problem :-)

                                Now their might be a list of a few things on the wall that act as a reminder for some stuff that we occasionally forget, or as a statement of our values. But the definition of "done" lives in the teams heads.

                                Cheers,

                                Adrian
                                --
                                http://quietstars.com adrianh@... twitter.com/adrianh
                                t. +44 (0)7752 419080 skype adrianjohnhoward del.icio.us/adrianh




                              • Justin Tauber
                                Theoretically, there shouldn t be any such thing as technical debt either, though, right? But then again, the repayment of technical debts might be a good way
                                Message 15 of 20 , Aug 17, 2011
                                  Theoretically, there shouldn't be any such thing as technical debt either, though, right? But then again, the repayment of technical  debts might be a good way of distinguishing "done" for a release, from "done" for an iteration.

                                  Interestingly, the timing for repayment of a ux debt has to be different. Refactoring the design in a prerelease iteration, say, will only get in the way of refactoring code, right? So you can really only repay ux debt in the next release.

                                  Justin Tauber
                                  @brtrx

                                  On 18/08/2011, at 2:54 AM, Anders Ramsay <andersr@...> wrote:

                                   

                                  On Wed, Aug 17, 2011 at 11:59 AM, Justin Tauber <anotherjustin@...> wrote:


                                  Which makes me wonder: is anyone working with a concept of "user debt" as a counterpart to "technical debt" ? 
                                   
                                  I like the concept of "user debt," as in we're indebted to the users :) 

                                  UX debt is often a reference to a feature which technically functions as requested but where the quality of the experience is low, e..g some stuff is not properly aligned, or the feel of the experience is clunky or whatever.

                                  Defining something that has UX debt as Done means you'll be delivering a half-baked UX, which goes to the core of the UX field's complaint about Agile.

                                  IMO, there should be no such thing as UX debt. Either the quality of the experience is appropriate for the product, context, and domain, or it is not.  (E.g. for an entertainment product, experience quality should likely be very high, for an enterprise product, this may be less critical.)

                                  If a feature is seen as Done in every other way except for experience quality, then a decision can be made to call it Done and create a new card that addresses the particular experience quality issues and add it to the backlog.

                                • Jon Innes
                                  Both technical debt and UX debt are real. Most teams can judge the amount of technical debt fairly well as they have engineers on the team who know how to.
                                  Message 16 of 20 , Aug 18, 2011

                                    Both technical debt and UX debt are real. Most teams can judge the amount of technical debt fairly well as they have engineers on the team who know how to. That's not true for UX debt. That's because UX can only be judged directly by prospective end-users. Since few teams actually capture user feedback DURING development in a systematic and objective way and use it to guide their day to day work, most are unconsciously incompetent when it comes to UX. 

                                    As I said in my recent talk at Agile2011, "done" can only be defined by the end-users. Teams can try and judge it, but "good enough" to a bunch of engineers or the product owner may not be good enough for the market. This is why the vast majority of IT projects (and many startups) fail, they jump off the waterfall when it comes to user adoption. That's the core insight from UX that Agile doesn't typically consider. Marty Cagan's book "Inspired" talks about this is some detail.

                                    I'd disagree with Justin's point below. I've been on projects where we had considerable technical debt and UX debt. It was only when the development team was given the opportunity to redo existing functionality for technical reasons that we got a chance to address the UX debt.

                                    The key about UX debt is it is relative to the maturity of the market. Geoffrey Moore's book "Dealing with Darwin" and Don Norman's "Invisible Computer" cover this. The reason some products can survive with significant UX debt is that the market they sell to is immature, or it has bad user feedback loops so decisions aren't based on UX factors. As someone who has led UX teams at major enterprise software firms I can tell you that's the real reason most enterprise software firms get away with bad UX. However, the position of a product with significant UX debt is tenuous and largely sustained due to cost of switching products and other market forces. Some examples of how fast this changes in other markets--the table PC (MSFT was first to market) and the smart phone (Nokia).

                                    Jon Innes
                                    UX Innovation LLC
                                    @innes_jon

                                    On Aug 17, 2011, at 8:59 PM, Justin Tauber wrote:

                                     

                                    Theoretically, there shouldn't be any such thing as technical debt either, though, right? But then again, the repayment of technical  debts might be a good way of distinguishing "done" for a release, from "done" for an iteration.

                                    Interestingly, the timing for repayment of a ux debt has to be different. Refactoring the design in a prerelease iteration, say, will only get in the way of refactoring code, right? So you can really only repay ux debt in the next release.

                                    Justin Tauber
                                    @brtrx

                                    On 18/08/2011, at 2:54 AM, Anders Ramsay <andersr@...> wrote:

                                     

                                    On Wed, Aug 17, 2011 at 11:59 AM, Justin Tauber <anotherjustin@...> wrote:


                                    Which makes me wonder: is anyone working with a concept of "user debt" as a counterpart to "technical debt" ? 
                                     
                                    I like the concept of "user debt," as in we're indebted to the users :) 

                                    UX debt is often a reference to a feature which technically functions as requested but where the quality of the experience is low, e..g some stuff is not properly aligned, or the feel of the experience is clunky or whatever.

                                    Defining something that has UX debt as Done means you'll be delivering a half-baked UX, which goes to the core of the UX field's complaint about Agile.

                                    IMO, there should be no such thing as UX debt. Either the quality of the experience is appropriate for the product, context, and domain, or it is not.  (E.g. for an entertainment product, experience quality should likely be very high, for an enterprise product, this may be less critical.)

                                    If a feature is seen as Done in every other way except for experience quality, then a decision can be made to call it Done and create a new card that addresses the particular experience quality issues and add it to the backlog.



                                  • Adrian Howard
                                    Hi Gene, I think I m probably making my point badly. Let me try and clarify :-) ... Some questions: What progress are we trying to measure? What s the utility
                                    Message 17 of 20 , Aug 18, 2011
                                      Hi Gene,

                                      I think I'm probably making my point badly. Let me try and clarify :-)

                                      On 17 Aug 2011, at 14:33, Gene Arch wrote:

                                      > I must respectfully disagree with you, Adrian. The definition you
                                      > espouse seems to take the work outside of the iteration, which to me
                                      > seems to make it harder to really nail down what done is. Your
                                      > definition given below seems to lend itself to stories hanging out there without a definite resolution, which makes it difficult to show
                                      > progress.

                                      Some questions:

                                      What progress are we trying to measure?

                                      What's the utility of having a metric that shows the team progressing when the rest of the business disagrees?

                                      If we have stories hanging out there without a definite resolution is that a sign that:
                                      a) we should change our definition of "done"?
                                      b) we should figure out what's blocking those stories and fix the problem?

                                      > For instance, in your example of the MDs agreeing on a
                                      > feature being ok, what did you do in the event they disagreed?

                                      Simple - the story wasn't done :-)

                                      > Did a story sit out there until they could reconcile their differences?

                                      Yup.

                                      > Wouldn't it be better to agree upon what is acceptable relative to what you understand were the requirements from the MDs,

                                      We had built a feature that management decided wasn't correct. How would counting this as done help the team or the business?

                                      > and if they can't agree on whether or not the feature is acceptable, then that's an issue outside the development iteration. Something that, as you stated, is a separate problem.

                                      It was a separate problem - but one that the team needed to address. Having the measured productivity drop gives us a powerful tool to help do that.

                                      Let me tell you about the 2xMD problem in a bit more detail. This is a slight simplification, but I think it gets the point across.

                                      The working context was a web app that was continually deployed, so we were measuring stories-done-throughput not stories-done-per-iteration.

                                      The two MDs (let's call them Bob and Alice) were very busy and often offsite. Bob was more available, but Alice was senior and knew more about the domain and customers.

                                      Most of the time progress was fine. Stories were done, passed dev/customer tests, and were deployed. Everybody happy.

                                      However, there were a couple of occasions where stuff was missed or misunderstood by the dev team. One time it caused a pretty serious issue with a client demo and nearly lost an important sale. We started implementing a bunch of changes that should help stop the problem happening again - but Alice asked to approve all stories before they were released. Alice approval became part of the team definition of "done".

                                      Alice was often unavailable. Throughput dropped dramatically. That was quickly noticed. We discussed the issue and Bob agreed to step in when Alice wasn't available. Throughput rose. Having "Alice or Bob sign off" as part of "done" helped us solve a problem.

                                      Well - almost solve it... Alice sometimes disagreed with Bob. Bob sometimes disagreed with Alice. So "done" started included "Bob and Alice had to sign off". Unsurprisingly throughput slowed again. It wasn't as bad as before since Bob helped us spot some problems earlier and fix 'em. He also helped spread the domain knowledge around the rest of the team more - so we started spotting some of the problems ourselves. But Alice was still a bottleneck - and we could show it *because* we had a very restrictive and tight definition of done.

                                      That meant we could have a conversation with Bob and Alice about the relative value in the off-site work they were doing, compared to the value them being available as domain experts, and to help verify stories were doing what they wanted them to do.

                                      That conversation, over time, resulted in various tweaks to the product development process that removed the bottleneck (a combination of arranging more time with Alice, more education of the team as a whole about the domain, and a tweaked release process that pushed features out to a smaller audience first, some FIT-ish tests to help make some domain knowledge explicit, etc.).

                                      Does that make it more obvious why having the MD sign of form part of our definition of done? It helped us figure out problems that needed fixing.

                                      > I have difficulty with anything living "inside the team's heads,"
                                      > because when it does, it is often subject to misinterpretation and
                                      > hidden assumptions. If the team documents their definition of done in a tangible manner and keeps it close, then in the event of disagreements during an iteration, they can bring it out and point to it as a reference point for the discussion.
                                      >
                                      > I'm not saying the definition is the end-all be-all (it necessarily should be reviewed on a regular basis and updated based on new information), but to leave it to the team's individual assumptions seems dangerous to me.

                                      I'm not necessarily against there being documentation of the definition of done - but the value is in the agreement. Not the document. Especially since in many contexts what counts as "done" for different stories at different times can be very different.

                                      > I may be misunderstanding you, and if so, I apologize. I am also a
                                      > relatively new practitioner of agile, so I could be off my rocker as
                                      > well, but this is how I understand it.


                                      You're definitely not off your rocker :)

                                      Cheers,

                                      Adrian
                                      --
                                      http://quietstars.com adrianh@... twitter.com/adrianh
                                      t. +44 (0)7752 419080 skype adrianjohnhoward del.icio.us/adrianh
                                    • Gene Arch
                                      Thanks for your precise response to my message, Adrian. I better understand the situation, and it makes more sense. I think in my organization, we put a lot
                                      Message 18 of 20 , Aug 18, 2011
                                        Thanks for your precise response to my message, Adrian.  I better understand the situation, and it makes more sense.  I think in my organization, we put a lot of emphasis on stories-done-per-iteration, and that's where I was getting the confusion.  I'm now wondering if we should look at your way of doing it, as we have a similar issue with a client team that is offsite, sometimes disagrees, and likes control. 
                                         
                                        It's always educational to read your posts, Adrian, so thank you very much for humoring me :)
                                         
                                        ~Gene


                                        From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Adrian Howard
                                        Sent: Thursday, August 18, 2011 11:29 AM
                                        To: agile-usability@yahoogroups.com
                                        Subject: Re: [agile-usability] What's your definition of done?

                                         

                                        Hi Gene,

                                        I think I'm probably making my point badly. Let me try and clarify :-)

                                        On 17 Aug 2011, at 14:33, Gene Arch wrote:

                                        > I must respectfully disagree with you, Adrian. The definition you
                                        > espouse seems to take the work outside of the iteration, which to me
                                        > seems to make it harder to really nail down what done is. Your
                                        > definition given below seems to lend itself to stories hanging out there without a definite resolution, which makes it difficult to show
                                        > progress.

                                        Some questions:

                                        What progress are we trying to measure?

                                        What's the utility of having a metric that shows the team progressing when the rest of the business disagrees?

                                        If we have stories hanging out there without a definite resolution is that a sign that:
                                        a) we should change our definition of "done"?
                                        b) we should figure out what's blocking those stories and fix the problem?

                                        > For instance, in your example of the MDs agreeing on a
                                        > feature being ok, what did you do in the event they disagreed?

                                        Simple - the story wasn't done :-)

                                        > Did a story sit out there until they could reconcile their differences?

                                        Yup.

                                        > Wouldn't it be better to agree upon what is acceptable relative to what you understand were the requirements from the MDs,

                                        We had built a feature that management decided wasn't correct. How would counting this as done help the team or the business?

                                        > and if they can't agree on whether or not the feature is acceptable, then that's an issue outside the development iteration. Something that, as you stated, is a separate problem.

                                        It was a separate problem - but one that the team needed to address. Having the measured productivity drop gives us a powerful tool to help do that.

                                        Let me tell you about the 2xMD problem in a bit more detail. This is a slight simplification, but I think it gets the point across.

                                        The working context was a web app that was continually deployed, so we were measuring stories-done-throughput not stories-done-per-iteration.

                                        The two MDs (let's call them Bob and Alice) were very busy and often offsite. Bob was more available, but Alice was senior and knew more about the domain and customers.

                                        Most of the time progress was fine. Stories were done, passed dev/customer tests, and were deployed. Everybody happy.

                                        However, there were a couple of occasions where stuff was missed or misunderstood by the dev team. One time it caused a pretty serious issue with a client demo and nearly lost an important sale. We started implementing a bunch of changes that should help stop the problem happening again - but Alice asked to approve all stories before they were released. Alice approval became part of the team definition of "done".

                                        Alice was often unavailable. Throughput dropped dramatically. That was quickly noticed. We discussed the issue and Bob agreed to step in when Alice wasn't available. Throughput rose. Having "Alice or Bob sign off" as part of "done" helped us solve a problem.

                                        Well - almost solve it... Alice sometimes disagreed with Bob. Bob sometimes disagreed with Alice. So "done" started included "Bob and Alice had to sign off". Unsurprisingly throughput slowed again. It wasn't as bad as before since Bob helped us spot some problems earlier and fix 'em. He also helped spread the domain knowledge around the rest of the team more - so we started spotting some of the problems ourselves. But Alice was still a bottleneck - and we could show it *because* we had a very restrictive and tight definition of done.

                                        That meant we could have a conversation with Bob and Alice about the relative value in the off-site work they were doing, compared to the value them being available as domain experts, and to help verify stories were doing what they wanted them to do.

                                        That conversation, over time, resulted in various tweaks to the product development process that removed the bottleneck (a combination of arranging more time with Alice, more education of the team as a whole about the domain, and a tweaked release process that pushed features out to a smaller audience first, some FIT-ish tests to help make some domain knowledge explicit, etc.).

                                        Does that make it more obvious why having the MD sign of form part of our definition of done? It helped us figure out problems that needed fixing.

                                        > I have difficulty with anything living "inside the team's heads,"
                                        > because when it does, it is often subject to misinterpretation and
                                        > hidden assumptions. If the team documents their definition of done in a tangible manner and keeps it close, then in the event of disagreements during an iteration, they can bring it out and point to it as a reference point for the discussion.
                                        >
                                        > I'm not saying the definition is the end-all be-all (it necessarily should be reviewed on a regular basis and updated based on new information), but to leave it to the team's individual assumptions seems dangerous to me.

                                        I'm not necessarily against there being documentation of the definition of done - but the value is in the agreement. Not the document. Especially since in many contexts what counts as "done" for different stories at different times can be very different.

                                        > I may be misunderstanding you, and if so, I apologize. I am also a
                                        > relatively new practitioner of agile, so I could be off my rocker as
                                        > well, but this is how I understand it.

                                        You're definitely not off your rocker :)

                                        Cheers,

                                        Adrian
                                        --
                                        http://quietstars.com adrianh@... twitter.com/adrianh
                                        t. +44 (0)7752 419080 skype adrianjohnhoward del.icio.us/adrianh

                                      • Adrian Howard
                                        Hi Justin, ... I think unpacking done like that can be harmful. It s making the feedback loop longer, so it makes it much harder to fix problems sooner. For
                                        Message 19 of 20 , Aug 19, 2011
                                          Hi Justin,

                                          On 17 Aug 2011, at 16:59, Justin Tauber wrote:

                                          > Thanks for all the responses, they've been really useful.
                                          >
                                          > I get the impressions that there a few different concepts that need unpacking here:
                                          > * Done for an iteration vs done for a release
                                          > * Done as an internal standard prior to exposure to customers vs done from the perspective of the customer

                                          I think unpacking "done" like that can be harmful. It's making the feedback loop longer, so it makes it much harder to fix problems sooner.

                                          For example if a story is "done" for an iteration, but not "done" for a release - when do we figure out it's not really "done" for a release? How is putting off that level of "done" until later helping us?

                                          The relentless focus of good agile teams on done _really_ meaning done is a huge advantage for me and one I'd be reluctant to give up. It's the driver behind getting all necessary people involved with the project.

                                          > Though I can see how from both an agile and a ux perspective there shouldn't be a standard that isn't end user focused, from a practical perspective it's hard to learn from usability tests run on buggy software, so some "internal" standards need to be adopted. From that perspective, Jeff's definition of done looks like meaning "ready to expose to usability testing".

                                          Actually I think there's quite a lot the team can learn from usability testing buggy software ;-) I know I've learned include things like:

                                          * Participants don't notice a feature is buggy
                                          * Participants never use the buggy feature
                                          * Participants notice, but work around, the buggy feature
                                          * Participants see the bug as a feature

                                          all of which have interesting effects on how we might prioritise features and future work.

                                          Cheers,

                                          Adrian
                                          --
                                          http://quietstars.com adrianh@... twitter.com/adrianh
                                          t. +44 (0)7752 419080 skype adrianjohnhoward del.icio.us/adrianh
                                        • Adrian Howard
                                          Hi Anders, On 17 Aug 2011, at 17:54, Anders Ramsay wrote: [snip] ... [snip] I think it depends on the particular way the debt metaphor is being used. If you re
                                          Message 20 of 20 , Aug 19, 2011
                                            Hi Anders,

                                            On 17 Aug 2011, at 17:54, Anders Ramsay wrote:
                                            [snip]
                                            > Defining something that has UX debt as Done means you'll be delivering a
                                            > half-baked UX, which goes to the core of the UX field's complaint about
                                            > Agile.
                                            >
                                            > IMO, there should be no such thing as UX debt. Either the quality of the
                                            > experience is appropriate for the product, context, and domain, or it is
                                            > not. (E.g. for an entertainment product, experience quality should likely
                                            > be very high, for an enterprise product, this may be less critical.)
                                            [snip]

                                            I think it depends on the particular way the debt metaphor is being used.

                                            If you're using it in the more general "debt is bad" sense then I agree completely. If you produce a poor UX, just like if you produce bad code, and don't care then your product is f*cked in anything but the short term.

                                            However the metaphor was originally a little bit more nuanced than that. It's more about how taking on a technical debt, and then paying it off later, can be the right thing to do in some circumstances - just like taking on a financial debt. There's a nice video from Ward on the topic here http://www.youtube.com/watch?v=pqeJFYwnkjE (It's only 5mins long).

                                            Having debt is fine - if it's done in a mindful manner with the intent of paying the debt off.

                                            Cheers,

                                            Adrian
                                            --
                                            http://quietstars.com adrianh@... twitter.com/adrianh
                                            t. +44 (0)7752 419080 skype adrianjohnhoward del.icio.us/adrianh
                                          Your message has been successfully submitted and would be delivered to recipients shortly.