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

Re: [scrumdevelopment] Re: The velocity of the team...slippery "done" issues

Expand Messages
  • mpkirby
    ... In our company we formally recognize 3 phases of development (this is independent of the use of agile techniques). Code Development , Hardening , and
    Message 1 of 28 , Feb 12, 2008
      > 1) Most companies never notice the difference between "end-of-sprint
      > done" and "shippable", so they never talk about it.

      In our company we formally recognize 3 phases of development (this is
      independent of the use of agile techniques).

      "Code Development", "Hardening", and "Final acceptance by the program"

      Basically we do our development against prototype hardware, or "early
      production" hardware. When we think we have the feature content in, we
      go to a phase where all features are declared "done", and only "bug
      fixes" are accepted into the release.

      At some point in time the bug fixes largely subside, and the program
      starts taking the software/hardware to prepare everything for a
      world-wide launch.

      We'll get more bugs at this phase too, but not in large numbers.

      When we started to apply agile techniques, one of our goals was to
      reduce the length of the middle phase ('hardening"). We consider it
      mainly waste, and it sucks up a lot of time (typically 1 to 1.5 times
      the length of the "code development" phase.

      There is not much we can do about the last phase (as that is governed by
      lots of other considerations including training, documentation,
      manufacturing, other software development organizations, etc).

      For us, "done" ultimately means that our acceptance tests verify that
      the new functionality works (no bugs), and doesn't break anything else
      (no regression).

      "Shippable" is what happens at the end of the third phase, and it is not
      possible (practical) in our current organization/funding structure /
      legacy code / manufacturing / hardware dependencies/etc to incorporate
      that definition of "done" into every iteration.

      We aren't delusional in thinking we can completely eliminate the idea of
      "hardening". But steady consistent reduction over time is the goal.

      Mike
    • Dan Rawsthorne
      I have three definitions of done for a release: feature complete, code complete, and shippable. These roughly correspond to yours, as well...Each of these
      Message 2 of 28 , Feb 12, 2008
        I have three definitions of done for a release: feature complete, code
        complete, and shippable. These roughly correspond to yours, as
        well...Each of these definitions is subjective, and belong to the PO. In
        any case, the stories and sprints that one actually does to get there
        have their own objective definitions of done, and this definition is
        negotiated between the PO and the team.

        Dan Rawsthorne, PhD, CST
        Senior Coach, Danube Technologies
        dan@..., 425-269-8628



        mpkirby wrote:
        >
        > > 1) Most companies never notice the difference between "end-of-sprint
        > > done" and "shippable", so they never talk about it.
        >
        > In our company we formally recognize 3 phases of development (this is
        > independent of the use of agile techniques).
        >
        > "Code Development", "Hardening", and "Final acceptance by the program"
        >
        > Basically we do our development against prototype hardware, or "early
        > production" hardware. When we think we have the feature content in, we
        > go to a phase where all features are declared "done", and only "bug
        > fixes" are accepted into the release.
        >
        > At some point in time the bug fixes largely subside, and the program
        > starts taking the software/hardware to prepare everything for a
        > world-wide launch.
        >
        > We'll get more bugs at this phase too, but not in large numbers.
        >
        > When we started to apply agile techniques, one of our goals was to
        > reduce the length of the middle phase ('hardening"). We consider it
        > mainly waste, and it sucks up a lot of time (typically 1 to 1.5 times
        > the length of the "code development" phase.
        >
        > There is not much we can do about the last phase (as that is governed by
        > lots of other considerations including training, documentation,
        > manufacturing, other software development organizations, etc).
        >
        > For us, "done" ultimately means that our acceptance tests verify that
        > the new functionality works (no bugs), and doesn't break anything else
        > (no regression).
        >
        > "Shippable" is what happens at the end of the third phase, and it is not
        > possible (practical) in our current organization/funding structure /
        > legacy code / manufacturing / hardware dependencies/etc to incorporate
        > that definition of "done" into every iteration.
        >
        > We aren't delusional in thinking we can completely eliminate the idea of
        > "hardening". But steady consistent reduction over time is the goal.
        >
        > Mike
        >
        >
      • Tobias Mayer
        ... Not to play oneupmanship, but we have 4 levels of done... Done Really done! Okay, really, truly done this time. Srsly Production server? and then
        Message 3 of 28 , Feb 13, 2008
          > I have three definitions of done for a release...

          Not to play oneupmanship, but we have 4 levels of done... 

          "Done"
          "Really done!"
          "Okay, really, truly done this time.  Srsly"
          "Production server?"

          and then we have 4 levels of acceptance:

          "Okay, looks good"
          "What do you mean, run the code?
          "Unhandled what?"
          "Um, can you define 'Done' again for me? k thx"

          Tobias




          --- In scrumdevelopment@yahoogroups.com, Dan Rawsthorne <dan.rawsthorne@...> wrote:
          >
          > I have three definitions of done for a release: feature complete, code
          > complete, and shippable. These roughly correspond to yours, as
          > well...Each of these definitions is subjective, and belong to the PO. In
          > any case, the stories and sprints that one actually does to get there
          > have their own objective definitions of done, and this definition is
          > negotiated between the PO and the team.
          >
          > Dan Rawsthorne, PhD, CST
          > Senior Coach, Danube Technologies
          > dan@..., 425-269-8628
          >
          >
          >
          > mpkirby wrote:
          > >
          > > > 1) Most companies never notice the difference between "end-of-sprint
          > > > done" and "shippable", so they never talk about it.
          > >
          > > In our company we formally recognize 3 phases of development (this is
          > > independent of the use of agile techniques).
          > >
          > > "Code Development", "Hardening", and "Final acceptance by the program"
          > >
          > > Basically we do our development against prototype hardware, or "early
          > > production" hardware. When we think we have the feature content in, we
          > > go to a phase where all features are declared "done", and only "bug
          > > fixes" are accepted into the release.
          > >
          > > At some point in time the bug fixes largely subside, and the program
          > > starts taking the software/hardware to prepare everything for a
          > > world-wide launch.
          > >
          > > We'll get more bugs at this phase too, but not in large numbers.
          > >
          > > When we started to apply agile techniques, one of our goals was to
          > > reduce the length of the middle phase ('hardening"). We consider it
          > > mainly waste, and it sucks up a lot of time (typically 1 to 1.5 times
          > > the length of the "code development" phase.
          > >
          > > There is not much we can do about the last phase (as that is governed by
          > > lots of other considerations including training, documentation,
          > > manufacturing, other software development organizations, etc).
          > >
          > > For us, "done" ultimately means that our acceptance tests verify that
          > > the new functionality works (no bugs), and doesn't break anything else
          > > (no regression).
          > >
          > > "Shippable" is what happens at the end of the third phase, and it is not
          > > possible (practical) in our current organization/funding structure /
          > > legacy code / manufacturing / hardware dependencies/etc to incorporate
          > > that definition of "done" into every iteration.
          > >
          > > We aren't delusional in thinking we can completely eliminate the idea of
          > > "hardening". But steady consistent reduction over time is the goal.
          > >
          > > Mike
          > >
          > >
          >
        • Michael James
          Another approach, which strikes me as simpler and works for many teams, is to stick to Scrum s classic *potentially shippable product increment*. Potentially
          Message 4 of 28 , Feb 13, 2008
            Another approach, which strikes me as simpler and works for many teams, is to stick to
            Scrum's classic *potentially shippable product increment*. "Potentially shippable" as in
            shippable within one stabilization Sprint. Sure it's hard to do, but compromising "done"
            beyond this is asking for trouble, IMO.

            --mj
          • aacockburn
            ... teams, is to stick to ... increment*. Potentially shippable as in ... but compromising done ... I don t know how to safely assert the amount of
            Message 5 of 28 , Feb 13, 2008
              --- In scrumdevelopment@yahoogroups.com, "Michael James"
              <michael@...> wrote:
              >
              > Another approach, which strikes me as simpler and works for many
              teams, is to stick to
              > Scrum's classic *potentially shippable product
              increment*. "Potentially shippable" as in
              > shippable within one stabilization Sprint. Sure it's hard to do,
              but compromising "done"
              > beyond this is asking for trouble, IMO.
              >
              > --mj
              >

              I don't know how to safely assert the amount of "nearly shippable"
              code that can honestly, truly be made shippable within exactly one
              stabilization sprint.

              In my experience, people underestimate how long it takes to make
              things really ready for shipping.

              How do you decide that?

              (The even simpler method is the one a few teams do, and Laurent
              alluded to --- release to production every single sprint, and then
              you'll quickly learn how much you can really fit into a sprint)

              Alistair
            • Michael James
              ... Yes, exactly. We teach ScrumMasters to expand the definition of done to include all work. What is everyone working on that s more important than the
              Message 6 of 28 , Feb 14, 2008
                --- In scrumdevelopment@yahoogroups.com, "aacockburn" <acockburn@...> wrote:

                > In my experience, people underestimate how long it takes to make
                > things really ready for shipping.

                Yes, exactly. We teach ScrumMasters to expand the
                definition of "done" to include all work.

                What is everyone working on that's more important
                than the ability to deliver products to customers?
                Once we can do that, *then* let's talk about
                increasing scope. Unshipped inventory is
                waste, and potentially-unshippable inventory
                is debt.

                >
                > How do you decide that?

                Typically by guessing wrong, then finding out as
                quickly as possible about our wrong guesses.
                If it's not truly shippable at the end of our
                stabilization Sprint we adapt our definition
                of "done" for future Sprints.

                In trying, and sometimes failing, we discover
                what "potentially shippable product increment"
                means for us.


                > (The even simpler method is the one a few teams do, and Laurent
                > alluded to --- release to production every single sprint, and then
                > you'll quickly learn how much you can really fit into a sprint)

                I've even heard of teams that claim you could
                take their build any given day of the week and
                send it out the door (with full testing, user
                documents, etc.). Most businesses don't need
                to be *that* agile!

                --mj
              • quinton@serv.net
                This is too depressing for management! (The even simpler method is the one a few teams do, and Laurent alluded to --- release to production every single
                Message 7 of 28 , Feb 14, 2008
                  This is too depressing for management!

                  (The even simpler method is the one a few teams do, and Laurent
                  alluded to --- release to production every single sprint, and then
                  you'll quickly learn how much you can really fit into a sprint)




                  > --- In scrumdevelopment@yahoogroups.com, "aacockburn" <acockburn@...>
                  > wrote:
                  >
                  >> In my experience, people underestimate how long it takes to make
                  >> things really ready for shipping.
                  >
                  > Yes, exactly. We teach ScrumMasters to expand the
                  > definition of "done" to include all work.
                  >
                  > What is everyone working on that's more important
                  > than the ability to deliver products to customers?
                  > Once we can do that, *then* let's talk about
                  > increasing scope. Unshipped inventory is
                  > waste, and potentially-unshippable inventory
                  > is debt.
                  >
                  >>
                  >> How do you decide that?
                  >
                  > Typically by guessing wrong, then finding out as
                  > quickly as possible about our wrong guesses.
                  > If it's not truly shippable at the end of our
                  > stabilization Sprint we adapt our definition
                  > of "done" for future Sprints.
                  >
                  > In trying, and sometimes failing, we discover
                  > what "potentially shippable product increment"
                  > means for us.
                  >
                  >
                  >> (The even simpler method is the one a few teams do, and Laurent
                  >> alluded to --- release to production every single sprint, and then
                  >> you'll quickly learn how much you can really fit into a sprint)
                  >
                  > I've even heard of teams that claim you could
                  > take their build any given day of the week and
                  > send it out the door (with full testing, user
                  > documents, etc.). Most businesses don't need
                  > to be *that* agile!
                  >
                  > --mj
                  >
                  >
                • Mike Vizdos
                  Hi, This is a great thread and topic I run into when working with teams often. It is scary how often this comes up and how people start rationalizing done.
                  Message 8 of 28 , Feb 14, 2008
                    Hi,

                    This is a great thread and topic I run into when working with teams often.  It is scary how often this comes up and how people start "rationalizing" done.

                    I actually posted a cartoon this week about how teams look at "Done" and you can see more at:


                    and


                    Hope they help with starting some conversations!

                    Thank you,

                    - Mike Vizdos
                      CST
                      
                     Contact Information

                              Web:      www.implementingscrum.com
                                              www.michaelvizdos.com



                    On Feb 14, 2008, at 12:56 PM, quinton@... wrote:

                    This is too depressing for management!

                    (The even simpler method is the one a few teams do, and Laurent
                    alluded to --- release to production every single sprint, and then
                    you'll quickly learn how much you can really fit into a sprint)

                    > --- In scrumdevelopment@ yahoogroups. com, "aacockburn" <acockburn@. ..>
                    > wrote:
                    >
                    >> In my experience, people underestimate how long it takes to make
                    >> things really ready for shipping.
                    >
                    > Yes, exactly. We teach ScrumMasters to expand the
                    > definition of "done" to include all work.
                    >
                    > What is everyone working on that's more important
                    > than the ability to deliver products to customers?
                    > Once we can do that, *then* let's talk about
                    > increasing scope. Unshipped inventory is
                    > waste, and potentially- unshippable inventory
                    > is debt.
                    >
                    >>
                    >> How do you decide that?
                    >
                    > Typically by guessing wrong, then finding out as
                    > quickly as possible about our wrong guesses.
                    > If it's not truly shippable at the end of our
                    > stabilization Sprint we adapt our definition
                    > of "done" for future Sprints.
                    >
                    > In trying, and sometimes failing, we discover
                    > what "potentially shippable product increment"
                    > means for us.
                    >
                    >
                    >> (The even simpler method is the one a few teams do, and Laurent
                    >> alluded to --- release to production every single sprint, and then
                    >> you'll quickly learn how much you can really fit into a sprint)
                    >
                    > I've even heard of teams that claim you could
                    > take their build any given day of the week and
                    > send it out the door (with full testing, user
                    > documents, etc.). Most businesses don't need
                    > to be *that* agile!
                    >
                    > --mj
                    >
                    >


                  • Michael James
                    ... I ve observed clever mental gymnastics to wiggle out of potentially shippable product increment from people who should know better: demonstrably done (so
                    Message 9 of 28 , Feb 14, 2008
                      --- In scrumdevelopment@yahoogroups.com, Mike Vizdos <mvizdos@...> wrote:
                      > It is scary how often this comes up and how people start "rationalizing" done.
                      >

                      I've observed clever mental gymnastics to wiggle out of "potentially
                      shippable product increment" from people who should know better:
                      demonstrably done (so we're building demoware????)
                      as done as *we* can make it (because we're not a cross functional team)
                      our "product" is a spec (so we're doing waterfall?)

                      I guess this makes Scrum easier to sell and teach, but modifying
                      Scrum because it seems too hard robs our clients of growth
                      opportunities. Rather than succumb to Stockholm syndrome,
                      let's help reveal those organizational impediments for what
                      they are.

                      --mj
                    • mpkirby
                      It seems to me that incremental organizational improvement is as important as incremental software development. The real question we should be asking ourselves
                      Message 10 of 28 , Feb 14, 2008
                        It seems to me that incremental organizational improvement is as
                        important as incremental software development.

                        The real question we should be asking ourselves is that when we settle
                        for something less than the ideal, what are we going to do next
                        iteration that gets us closer to that ideal.

                        If we ultimately settle for mediocrity and decide that it is good
                        enough, then that culture will permeate everything we do, including our
                        products.

                        But there is a big difference between being "half way there" and "good
                        enough", even though at any given point in time the two organizations
                        are in the same spot.

                        Mike



                        Michael James wrote:
                        >
                        > --- In scrumdevelopment@yahoogroups.com, Mike Vizdos <mvizdos@...> wrote:
                        > > It is scary how often this comes up and how people start
                        "rationalizing" done.
                        > >
                        >
                        > I've observed clever mental gymnastics to wiggle out of "potentially
                        > shippable product increment" from people who should know better:
                        > demonstrably done (so we're building demoware????)
                        > as done as *we* can make it (because we're not a cross functional team)
                        > our "product" is a spec (so we're doing waterfall?)
                        >
                        > I guess this makes Scrum easier to sell and teach, but modifying
                        > Scrum because it seems too hard robs our clients of growth
                        > opportunities. Rather than succumb to Stockholm syndrome,
                        > let's help reveal those organizational impediments for what
                        > they are.
                      • Dan Rawsthorne
                        Michael, I love you but I take issue with the denigration of the term demonstrably done . Anything that must be demonstrated, must be demonstrably done. Since
                        Message 11 of 28 , Feb 14, 2008
                          Michael, I love you but I take issue with the denigration of the term "demonstrably done". Anything that must be demonstrated, must be demonstrably done. Since all completed work must be demonstrated, all stories must be demonstrably done. This phrase does not imply that done means demonstrable, only that when something is done, it must be demonstrably done. And the phrase "potentially shippable" means nothing to me, since the PO can ship anything he/she wants -- so anything is potentially shippable. Saying that this means that it is something that we would be willing to ship, or that it has the quality we want it to have as if we were shipping it, seems like a tautology to me. Either that, or we're saying to leave quality to the techies -- we're the professionals here -- and this doesn't seem like good teamwork to me

                          The way I see it, when we claim a story is "done", we should have done two things:
                            1. achieved the value the story represents in a way that can be demonstrated, and
                            2. not increased any project risk in the process

                          This second thing leads to the interesting conversations we are (or should be) having. There are many things involved, but part of the answer is that no technical debt (of any sort) should have increased when a story is "done". This seems (to me) to cover all the arguments we are having about this topic... and it's what my students respond to well. And it leads to real interesting convesations, which should be result of any definitions of this sort, IMHO.
                          Dan Rawsthorne, PhD, CST
                          Senior Coach, Danube Technologies
                          dan@..., 425-269-8628
                          Michael James wrote:

                          --- In scrumdevelopment@ yahoogroups. com, Mike Vizdos <mvizdos@... > wrote:
                          > It is scary how often this comes up and how people start "rationalizing" done.
                          >

                          I've observed clever mental gymnastics to wiggle out of "potentially
                          shippable product increment" from people who should know better:
                          demonstrably done (so we're building demoware???? )
                          as done as *we* can make it (because we're not a cross functional team)
                          our "product" is a spec (so we're doing waterfall?)

                          I guess this makes Scrum easier to sell and teach, but modifying
                          Scrum because it seems too hard robs our clients of growth
                          opportunities. Rather than succumb to Stockholm syndrome,
                          let's help reveal those organizational impediments for what
                          they are.

                          --mj

                        • Michael James
                          ... Yes, well said. Potentially shippable product increment is a *target* practice to work towards incrementally. --mj
                          Message 12 of 28 , Feb 14, 2008
                            --- In scrumdevelopment@yahoogroups.com, mpkirby <mpkirby@...> wrote:
                            >
                            > It seems to me that incremental organizational improvement is as
                            > important as incremental software development.
                            >

                            Yes, well said. "Potentially shippable product increment" is a
                            *target* practice to work towards incrementally.

                            --mj
                          • Michael James
                            ... Not half as much as I love you! ... I d call demonstrably done a good start, not a target. Like nightly builds. I think most of us are aware of a huge
                            Message 13 of 28 , Feb 14, 2008
                              --- In scrumdevelopment@yahoogroups.com, Dan Rawsthorne <dan.rawsthorne@...> wrote:
                              >
                              > Michael, I love you

                              Not half as much as I love you!

                              > but I take issue with the denigration of the term
                              > "demonstrably done".

                              I'd call "demonstrably done" a good start, not a target.
                              Like nightly builds.

                              I think most of us are aware of a huge gulf between
                              demonstrable and shippable. Ken was on to something
                              when he wrote "potentially shippable product increment"
                              about 20 times in the gray book.

                              --mj
                            • Dan Rawsthorne
                              That s not the point. There is no inconsistency. Demonstrable is a requirement of doneness, not the definition of doneness. The term was first used (by me) to
                              Message 14 of 28 , Feb 15, 2008
                                That's not the point. There is no inconsistency. Demonstrable is a
                                requirement of doneness, not the definition of doneness. The term was
                                first used (by me) to describe what were appropriate stories, not what
                                does "done" mean. It comes up in the context like this "a story is
                                appropriate for a sprint backlog if the story can be demonstrably done;
                                that is, that the doneness criteria are demonstrable, so that becoming
                                done is objective, not subjective. Of course, being done (which we are
                                talking about) is a different thing. Being done means all the stuff we
                                agree on, but I ADD the requirement that being done must be demonstrable.

                                Just Sayin'

                                Dan Rawsthorne, PhD, CST
                                Senior Coach, Danube Technologies
                                dan@..., 425-269-8628



                                Michael James wrote:
                                >
                                > --- In scrumdevelopment@yahoogroups.com
                                > <mailto:scrumdevelopment%40yahoogroups.com>, Dan Rawsthorne
                                > <dan.rawsthorne@...> wrote:
                                > >
                                > > Michael, I love you
                                >
                                > Not half as much as I love you!
                                >
                                > > but I take issue with the denigration of the term
                                > > "demonstrably done".
                                >
                                > I'd call "demonstrably done" a good start, not a target.
                                > Like nightly builds.
                                >
                                > I think most of us are aware of a huge gulf between
                                > demonstrable and shippable. Ken was on to something
                                > when he wrote "potentially shippable product increment"
                                > about 20 times in the gray book.
                                >
                                > --mj
                                >
                                >
                              • Michael James
                                ... Oh. Well that makes sense! --mj
                                Message 15 of 28 , Feb 15, 2008
                                  --- In scrumdevelopment@yahoogroups.com, Dan Rawsthorne <dan.rawsthorne@...> wrote:
                                  >
                                  > That's not the point. There is no inconsistency. Demonstrable is a
                                  > requirement of doneness, not the definition of doneness.

                                  Oh. Well that makes sense!

                                  --mj
                                • George Dinwiddie
                                  ... Alistair, I think the proper term is potentially shippable rather than shippable . As Jeff Patton is wont to say, You aren t gonna ship it. ...
                                  Message 16 of 28 , Feb 18, 2008
                                    aacockburn wrote:
                                    > While I agree in general with what Laurent writes, I have been
                                    > noticing lately very many teams declaring "done" when it is not ready
                                    > to ship; and at the same time the iteration/sprint length is too
                                    > short to really get "done" in any meaningful way.
                                    >
                                    > More generally, I accept that there are times and places (lots of
                                    > them in fact), when "end of the sprint" appropriately produces a
                                    > result less than "shippable" (Laurent's "done"). This is not a
                                    > violation of Scrum - the original description Ken Schwaber gave of
                                    > end-of-sprint was a demo!

                                    Alistair, I think the proper term is "potentially shippable" rather than
                                    "shippable". As Jeff Patton is wont to say, "You aren't gonna ship it."

                                    > The question meaningfully becomes, supposing there is a legal and
                                    > valid difference between "end-of-sprint done" and "shippable", what
                                    > to do about it.
                                    >
                                    > In http://alistair.cockburn.us/index.php/Three_cards_for_user_rights
                                    > (the section is http://tinyurl.com/2knmbd), I offer a simple
                                    > technique for managing the difference.
                                    >
                                    > However, more interesting than the technique is the (absence of)
                                    > dialog inside the company, and the ripple effects.
                                    > 1) Most companies never notice the difference between "end-of-sprint
                                    > done" and "shippable", so they never talk about it.
                                    > 2) Most programmers don't have any idea how much work it takes to get
                                    > from "end-of-sprint done" and "shippable", so neither they nor their
                                    > managers schedule it!
                                    > 3) Following from (2), there isn't an orchestrated dialog between the
                                    > parties as to how to schedule and evaluate the allegedly-shippable
                                    > version.
                                    [snip]
                                    > Obviously, people and projects slip around a lot on this issue.
                                    >
                                    > The best is to do as Laurent writes, and (a) make the sprints long
                                    > enough that
                                    > (a) users can see and correct the feature within the sprint period,
                                    > (b) everyone can get the feature fully shippable, consumer-grade (or
                                    > whatever you need), within the sprint period.
                                    >
                                    > It simplifies discussion and planning a lot.

                                    I would like to propose an alternative to your first (a): that is, to
                                    become practiced at slicing the functionality into small slivers such
                                    that it can be production quality within a short sprint, rather than
                                    lengthening the sprint.

                                    - George

                                    --
                                    ----------------------------------------------------------------------
                                    * George Dinwiddie * http://blog.gdinwiddie.com
                                    Software Development http://www.idiacomputing.com
                                    Consultant and Coach http://www.agilemaryland.org
                                    ----------------------------------------------------------------------
                                  • jgabardini
                                    ... I agree. Why is velocity value so important to you (Tomi)? The team didn t deliver the whole committed work. Ok, let s learn why (insert the thread of
                                    Message 17 of 28 , Feb 21, 2008
                                      --- In scrumdevelopment@yahoogroups.com, Laurent Bossavit <laurent@...> wrote:
                                      >
                                      > > By summing this up, what is the velocity for team which does not
                                      > > meet the sprint goal (undone tasks)?
                                      >
                                      >
                                      > In your example the velocity is 24.
                                      >
                                      > Scrum recognizes only two degrees of "Done":
                                      > - Done (100%), and
                                      > - not Done (0%)
                                      >

                                      I agree.

                                      Why is velocity value so important to you (Tomi)?

                                      The team didn't deliver the whole committed work.

                                      Ok, let's learn why (insert the thread of "done" here)

                                      But is it ok to fail, not to often, not to much, maybe (a new thread on common and special causes here :)  )

                                       

                                      I sometimes feel that teams overreact to (partial) failure. Some of the things that you learned this "failed" sprint would help you speed up the next one.

                                       

                                      For instance, I expect that the definition of done will slowly change over time. If the team fail frequently, it could be a bad "done" definition or bad estimation. If bad estimation is the problem, changing the "done" definition will do more harm.

                                       

                                      Juan


                                    • Tony
                                      I m probably repeating what was already said but from our team s perspective and mentoring, I regard stories as Done or Not Done. Even if the Not Done is at
                                      Message 18 of 28 , Feb 21, 2008
                                        I'm probably repeating what was already said but from our team's
                                        perspective and mentoring, I regard stories as Done or Not Done. Even
                                        if the Not Done is at 99%, its still going to count as 0 story points
                                        in our burn up chart.

                                        After our sprint, we then see if it makes the priority list for the
                                        next sprint and add accordingly.

                                        As a new team, we are still learning the amount of story points we can
                                        adequetly handle, in our 2nd iteration, we made some mistakes in story
                                        planning but the benefit is we learned from it.

                                        I think the entire thing is a learning process and never ends from
                                        this n00b's pov.
                                      • Roy Morien
                                        I agree entirely on the Done/Not Done viewpoint, but I have a concern about that in regard to the calculation of sprint velocity. If we take the worse case
                                        Message 19 of 28 , Feb 22, 2008
                                          I agree entirely on the Done/Not Done viewpoint, but I have a concern about that in regard to the calculation of sprint velocity. If we take the worse case scenario, someone is 99% finished on their one and only task for the sprint. As it is not done, it is 0 story points achieved in the sprint. Where does that leave sprint velocity?
                                           
                                          Regards,
                                          Roy Morien





                                          To: scrumdevelopment@yahoogroups.com
                                          From: tpagliocco@...
                                          Date: Fri, 22 Feb 2008 07:54:14 +0000
                                          Subject: [scrumdevelopment] Re: The velocity of the team...

                                          I'm probably repeating what was already said but from our team's
                                          perspective and mentoring, I regard stories as Done or Not Done. Even
                                          if the Not Done is at 99%, its still going to count as 0 story points
                                          in our burn up chart.

                                          After our sprint, we then see if it makes the priority list for the
                                          next sprint and add accordingly.

                                          As a new team, we are still learning the amount of story points we can
                                          adequetly handle, in our 2nd iteration, we made some mistakes in story
                                          planning but the benefit is we learned from it.

                                          I think the entire thing is a learning process and never ends from
                                          this n00b's pov.




                                          Check our comprehensive Salary Centre Overpaid or Underpaid?
                                        • Tobias Mayer
                                          ... Jagged. But it all balances out over time. I m curious as to why you switched the focus to tasks here, and to one person (rather than story and team).
                                          Message 20 of 28 , Feb 22, 2008
                                            > Where does that leave sprint velocity?
                                            Jagged.  But it all balances out over time.

                                            I'm curious as to why you switched the focus to tasks here, and to one person (rather than story and team).

                                            Tobias


                                            --- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@...> wrote:
                                            >
                                            > I agree entirely on the Done/Not Done viewpoint, but I have a concern about that in regard to the calculation of sprint velocity. If we take the worse case scenario, someone is 99% finished on their one and only task for the sprint. As it is not done, it is 0 story points achieved in the sprint. Where does that leave sprint velocity?
                                            >
                                            > Regards,
                                            > Roy Morien
                                            >
                                            >
                                            > To: scrumdevelopment@...: tpagliocco@...: Fri, 22 Feb 2008 07:54:14 +0000Subject: [scrumdevelopment] Re: The velocity of the team...
                                            >
                                            >
                                            >
                                            >
                                            > I'm probably repeating what was already said but from our team'sperspective and mentoring, I regard stories as Done or Not Done. Evenif the Not Done is at 99%, its still going to count as 0 story pointsin our burn up chart. After our sprint, we then see if it makes the priority list for thenext sprint and add accordingly.As a new team, we are still learning the amount of story points we canadequetly handle, in our 2nd iteration, we made some mistakes in storyplanning but the benefit is we learned from it.I think the entire thing is a learning process and never ends fromthis n00b's pov.
                                            >
                                            >
                                            >
                                            >
                                            >
                                            >
                                            > _________________________________________________________________
                                            > Overpaid or Underpaid? Check our comprehensive Salary Centre
                                            > http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fcontent%2Emycareer%2Ecom%2Eau%2Fsalary%2Dcentre%3Fs%5Fcid%3D595810&_t=766724125&_r=Hotmail_Email_Tagline_MyCareer_Oct07&_m=EXT
                                            >
                                          • Roy Morien
                                            Sorry, I didn t really switch ... I was just careless with my words. I used task to indicate an activity being undertaken to complete the story
                                            Message 21 of 28 , Feb 23, 2008
                                              Sorry, I didn't really 'switch' ... I was just careless with my words. I used 'task' to indicate an activity being undertaken to complete the story requirements. And I was just thinking of a member of the team not contributing to the velocity calculation because of being 99% progressed, not Done.
                                               
                                              Another point comes to mind, partly in answer to my own question. I guess if you have a team of 7, 8, 10 people, and they all were 99% complete, it would indicate a problem with estimating story points. On the other hand, Done by most and 99% complete by some would average out over time. Right?
                                               
                                              Regards,
                                              Roy Morien





                                              To: scrumdevelopment@yahoogroups.com
                                              From: tobias.mayer@...
                                              Date: Sat, 23 Feb 2008 04:26:27 +0000
                                              Subject: [scrumdevelopment] Re: The velocity of the team...

                                              > Where does that leave sprint velocity?
                                              Jagged.  But it all balances out over time.

                                              I'm curious as to why you switched the focus to tasks here, and to one person (rather than story and team).

                                              Tobias


                                              --- In scrumdevelopment@ yahoogroups. com, Roy Morien <roymorien@.. .> wrote:
                                              >
                                              > I agree entirely on the Done/Not Done viewpoint, but I have a concern about that in regard to the calculation of sprint velocity. If we take the worse case scenario, someone is 99% finished on their one and only task for the sprint. As it is not done, it is 0 story points achieved in the sprint. Where does that leave sprint velocity?
                                              >
                                              > Regards,
                                              > Roy Morien
                                              >
                                              >
                                              > To: scrumdevelopment@ ...: tpagliocco@. ..: Fri, 22 Feb 2008 07:54:14 +0000Subject: [scrumdevelopment] Re: The velocity of the team...
                                              >
                                              >
                                              >
                                              >
                                              > I'm probably repeating what was already said but from our team'sperspective and mentoring, I regard stories as Done or Not Done. Evenif the Not Done is at 99%, its still going to count as 0 story pointsin our burn up chart. After our sprint, we then see if it makes the priority list for thenext sprint and add accordingly. As a new team, we are still learning the amount of story points we canadequetly handle, in our 2nd iteration, we made some mistakes in storyplanning but the benefit is we learned from it.I think the entire thing is a learning process and never ends fromthis n00b's pov.
                                              >
                                              >
                                              >
                                              >
                                              >
                                              >
                                              > ____________ _________ _________ _________ _________ _________ ________
                                              > Overpaid or Underpaid? Check our comprehensive Salary Centre
                                              > http://a.ninemsn. com.au/b. aspx?URL= http%3A%2F% 2Fcontent% 2Emycareer% 2Ecom%2Eau% 2Fsalary% 2Dcentre% 3Fs%5Fcid% 3D595810&_t=766724125&_r=Hotmail_Email_ Tagline_MyCareer _Oct07&_m=EXT
                                              >



                                              Check our comprehensive Salary Centre Overpaid or Underpaid?
                                            • George Dinwiddie
                                              ... Roy, I would say that the first red flag is raised when there in only one task (or story) in the sprint. That says to me that things are not being broken
                                              Message 22 of 28 , Feb 23, 2008
                                                Roy Morien wrote:
                                                > I agree entirely on the Done/Not Done viewpoint, but I have a concern
                                                > about that in regard to the calculation of sprint velocity. If we take
                                                > the worse case scenario, someone is 99% finished on their one and only
                                                > task for the sprint. As it is not done, it is 0 story points achieved in
                                                > the sprint. Where does that leave sprint velocity?

                                                Roy, I would say that the first red flag is raised when there in only
                                                one task (or story) in the sprint. That says to me that things are not
                                                being broken into small enough piece. I could go into more detail of
                                                the issues, but calculation of sprint velocity is the least of the problems.

                                                - George

                                                --
                                                ----------------------------------------------------------------------
                                                * George Dinwiddie * http://blog.gdinwiddie.com
                                                Software Development http://www.idiacomputing.com
                                                Consultant and Coach http://www.agilemaryland.org
                                                ----------------------------------------------------------------------
                                              • Dhaval R. Panchal
                                                ... concern ... take ... only ... achieved in ... As initial guideline I believe that stories are either Done or Not-Done. Notion of 99% finished on a task is
                                                Message 23 of 28 , Feb 23, 2008

                                                  Roy Morien wrote:

                                                  > I agree entirely on the Done/Not Done viewpoint, but I have a concern
                                                  > about that in regard to the calculation of sprint velocity. If we take
                                                  > the worse case scenario, someone is 99% finished on their one and only
                                                  > task for the sprint. As it is not done, it is 0 story points achieved in
                                                  > the sprint. Where does that leave sprint velocity?

                                                  As initial guideline I believe that stories are either Done or Not-Done.

                                                  Notion of 99% finished on a task is very subjective as it depends on teams approach towards task breakdown.

                                                   

                                                  A couple of task break down approaches that I have observed:

                                                  a. Tasks along skill boundaries.

                                                  Example: code, code review unit tests, system tests etc.. [observed mainly in teams starting with agile s/w development]

                                                  b. Tasks along functionality encompassed by user story.

                                                  Example: enable search button functionality, enable search using special filters (“+”, “site:” etc) [observed in mature agile teams that follow XP practices]

                                                   

                                                  Key differentiation between above mentioned approaches of task breakdown is that

                                                  in approach [a] tasks do not meet definition of done when they are finished, where as

                                                  in approach [b] each individual task for the user story is finished when it fulfills definition of done.

                                                   

                                                  Since, Velocity is measure of the amount of work that a scrum team can call as “Done” within a sprint. A team that delivers functionality (code) as potentially shippable software (meets definition of Done) could count a portion of user story size in their velocity.

                                                  This is under the assumption that the product owner considers this subset of story as valuable.

                                                   

                                                  So IMHO, if a task is 99% finished and the task is along skill boundaries then the entire story should be considered as Not-Done, since the functionality is not in a potentially shippable state. However, if the last remaining task is 99% done and all other finished tasks represent some functionality for the story then size of remaining functionalities completed for that story can be included in sprint velocity.

                                                   

                                                  I also believe that this accounting complexity should be avoided at all costs. This can be achieved by holding prior conversations with Product Owner and negotiating a split for large or risky user stories prior to sprint completion.

                                                   

                                                   

                                                  Best Regards,

                                                  Dhaval Panchal

                                                  Sr. Analyst/Agile Coach

                                                  CSM (P)

                                                  SolutionsIQ

                                                  www.solutionsiq.com

                                                  10785 Willows Road NE, Suite 200

                                                  Redmond, WA , 98052

                                                  cell: 425-283-6184

                                                   

                                                  you must be the change you wish to see in the world - Mahatma Gandhi.

                                                   

                                                   


                                                  From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of George Dinwiddie
                                                  Sent: Saturday, February 23, 2008 5:30 PM
                                                  To: scrumdevelopment@yahoogroups.com
                                                  Subject: Re: [scrumdevelopment] Re: The velocity of the team...

                                                   

                                                  Roy Morien wrote:

                                                  > I agree entirely on the Done/Not Done viewpoint, but I have a concern
                                                  > about that in regard to the calculation of sprint velocity. If we take
                                                  > the worse case scenario, someone is 99% finished on their one and only
                                                  > task for the sprint. As it is not done, it is 0 story points achieved in
                                                  > the sprint. Where does that leave sprint velocity?

                                                  Roy , I would say that the first red flag is raised when there in only
                                                  one task (or story) in the sprint. That says to me that things are not
                                                  being broken into small enough piece. I could go into more detail of
                                                  the issues, but calculation of sprint velocity is the least of the problems.

                                                  - George

                                                  --
                                                  ------------ --------- --------- --------- --------- --------- -
                                                  * George Dinwiddie * http://blog. gdinwiddie. com
                                                  Software Development http://www.idiacomp uting.com
                                                  Consultant and Coach http://www.agilemar yland.org
                                                  ------------ --------- --------- --------- --------- --------- -

                                                • Bas Vodde
                                                  Hiya, Nice discussion! I always make a distinction between done and potentially shippable . As MJ says, potentially shippable is the goal is Scrum. To me
                                                  Message 24 of 28 , Mar 12, 2008
                                                    Hiya,

                                                    Nice discussion!

                                                    I always make a distinction between "done" and "potentially
                                                    shippable". As MJ says, potentially
                                                    shippable is the goal is Scrum. To me that would mean, whenever the PO
                                                    says "ship it!" then it
                                                    would, the next day (or earlier) be at the customer. This means that
                                                    an ideal "potentially shippable"
                                                    will reach far out the development organization.

                                                    "Done" is what the current organization is capable of. In smaller
                                                    projects, they are often the same
                                                    since it's not too hard to make stuff potentially shippable every
                                                    sprint. In large projects, getting
                                                    "done" to become "potentially shippable" will require huge changes in
                                                    the organization and in
                                                    the technology! Thus, "done" is their current capability and from the
                                                    day they start Scrum, the
                                                    teams goal is to improve and make it the same as potentially
                                                    shippable. For very large projects,
                                                    that might take years (which is mostly recovering from years and years
                                                    of technical dept).

                                                    I'd always measure stuff in DONE or NOT DONE as defined by the team
                                                    and the PO together.
                                                    99% done is not done and thus not included in velocity. I'f even
                                                    recommend to make the
                                                    "effort remaining" in the product backlog to be the same as the
                                                    original.

                                                    Bas


                                                    On Feb 15, 2008, at 1:53 AM, Michael James wrote:

                                                    > --- In scrumdevelopment@yahoogroups.com, mpkirby <mpkirby@...> wrote:
                                                    > >
                                                    > > It seems to me that incremental organizational improvement is as
                                                    > > important as incremental software development.
                                                    > >
                                                    >
                                                    > Yes, well said. "Potentially shippable product increment" is a
                                                    > *target* practice to work towards incrementally.
                                                    >
                                                    > --mj
                                                    >
                                                    >
                                                    >
                                                  Your message has been successfully submitted and would be delivered to recipients shortly.