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

The velocity of the team...

Expand Messages
  • Tomi Laaksonen
    Hello Scrum Community, I would like to get some help to question I started to wonder when our Scrum Team did not meet the Scrum Goal. What is the velocity of
    Message 1 of 28 , Feb 12, 2008
      Hello Scrum Community,

      I would like to get some help to question I started to wonder when our Scrum Team did not meet the Scrum Goal. What is the velocity of the team if the team cannot finalize all tasks during the sprint. As an example team commits to implemented x product backlog items (user stories) estimated totally 35 story points. Now end of the sprint there are undone tasks so that user stories A (8 story points) and B (3 story points) are partly done. The velocity is then 24 story points or is it? Or should those two user stories re-estimate to get understanding what has been done like user story A: 5 story points were done and rest will be moved to next sprint (and B: 1 points done, 2 undone). Then velocity could be 29 story points.

      By summing this up, what is the velocity for team which does not meet the sprint goal (undone tasks)?

      Br,

      -TT-


      Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
    • Laurent Bossavit
      ... 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
      Message 2 of 28 , Feb 12, 2008
        > 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@...
      • Michael James
        ... You said it! My own view is here: http://danube.com/blog/michaeljames/just_say_no_to_partial_credit.html ... How about we say the team negotiates it with
        Message 3 of 28 , Feb 12, 2008
          --- In scrumdevelopment@yahoogroups.com, Laurent Bossavit <laurent@...> wrote:
          >
          > 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.

          You said it!

          My own view is here:
          http://danube.com/blog/michaeljames/just_say_no_to_partial_credit.html

          >
          > The team owns the definition of "Done".

          How about we say the team negotiates it with the Product Owner?

          --mj
        • 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 4 of 28 , Feb 12, 2008
            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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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 22 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 23 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 24 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 25 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 26 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 27 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 28 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.