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

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

Expand Messages
  • aacockburn
    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
    Message 1 of 28 , Feb 12 9:24 AM
    • 0 Attachment
      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!

      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.

      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.

      Alistair


      --- 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%)
      >
      > There is no such thing as "almost Done", "partially Done" or "a
      > little Done". When figuring velocity, the team will do well to
      count
      > the points only for items that are completely Done.
      >
      > The team owns the definition of "Done". A good rule of thumb for
      > figuring out if the definition of "Done" is a good one is to see
      what
      > happens after an item is declared "Done". If there is any more
      work
      > afterwards that someone invests in the same item, then the team's
      > definition of "Done" is broken and needs improvement.
      >
      > "Oh yes it's done. I just need to document it now". That is not a
      > proper Done. Either change the definition so that "documented" is
      > part of what Done means, or systematically add "Document X" items
      to
      > the backlog. Ditto for "I just need to refactor", "I just need to
      > debug it", and so on.
      >
      > Laurent Bossavit
      > laurent@...
      >
    • 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 2 of 28 , Feb 12 10:55 AM
      • 0 Attachment
        > 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 3 of 28 , Feb 12 7:30 PM
        • 0 Attachment
          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 4 of 28 , Feb 13 5:21 AM
          • 0 Attachment
            > 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 5 of 28 , Feb 13 6:19 AM
            • 0 Attachment
              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 6 of 28 , Feb 13 8:11 PM
              • 0 Attachment
                --- 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 7 of 28 , Feb 14 9:35 AM
                • 0 Attachment
                  --- 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 8 of 28 , Feb 14 9:56 AM
                  • 0 Attachment
                    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 9 of 28 , Feb 14 12:43 PM
                    • 0 Attachment
                      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 10 of 28 , Feb 14 7:27 PM
                      • 0 Attachment
                        --- 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 11 of 28 , Feb 14 7:38 PM
                        • 0 Attachment
                          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 12 of 28 , Feb 14 8:53 PM
                          • 0 Attachment
                            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 13 of 28 , Feb 14 10:53 PM
                            • 0 Attachment
                              --- 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 14 of 28 , Feb 14 11:01 PM
                              • 0 Attachment
                                --- 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 15 of 28 , Feb 15 6:15 AM
                                • 0 Attachment
                                  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 16 of 28 , Feb 15 7:46 AM
                                  • 0 Attachment
                                    --- 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 17 of 28 , Feb 18 7:01 PM
                                    • 0 Attachment
                                      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 18 of 28 , Feb 21 3:48 AM
                                      • 0 Attachment
                                        --- 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 19 of 28 , Feb 21 11:54 PM
                                        • 0 Attachment
                                          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 20 of 28 , Feb 22 7:22 PM
                                          • 0 Attachment
                                            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 21 of 28 , Feb 22 8:26 PM
                                            • 0 Attachment
                                              > 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 22 of 28 , Feb 23 12:25 AM
                                              • 0 Attachment
                                                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 23 of 28 , Feb 23 5:29 PM
                                                • 0 Attachment
                                                  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 24 of 28 , Feb 23 7:53 PM
                                                  • 0 Attachment

                                                    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 25 of 28 , Mar 12, 2008
                                                    • 0 Attachment
                                                      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.