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

49465Re: [scrumdevelopment] Keeping cross-cutting tasks visible (without technical stories)

Expand Messages
  • Ron Jeffries
    Dec 1, 2010
    • 0 Attachment
      Hello, Roy. On Wednesday, December 1, 2010, at 3:29:27 AM, you
      wrote:

      > I think this notion of only ever doing things that have value to
      > the customer has been somewhat misunderstood, or misapplied. There
      > are most certainly things that need to be done that do not have an
      > immediate, direct, or even obvious value to a customer ... but
      > they still must be done. So what if user stories are not written
      > for them, and so what if they really don't fit the notion of user
      > stories (however defined). Being afraid to get it done because
      > Scrum doesn't seem to cover that situation just leads to
      > development paralysis.

      If one is to do Scrum well, one needs to understand Scrum well.
      Deviating from it every time something "seems" odd will not help a
      team to prosper. It troubles me that so much of your advice, Roy,
      deviates substantially from what Scrum and Agile teach, even when
      there are perfectly good Scrum / Agile answers.

      So here's so what.

      The fundamental point of Scrum is for the PO to prioritize work
      for the team, so that the best possible product can be delivered
      within the desired time and budget. The PO will get the best
      product if work is chosen that is of high "business value". (Low
      development cost is also a concern in choosing the work, but may
      will be substantially less important than value.)

      Clearly, the PO is capable of driving out more value when a larger
      percentage of the team's time comes under her control, since
      otherwise, she is directing a smaller flow of work, which will
      inherently reduce total value. Therefore it is undesirable to
      slice away a strip of the team's development time and make it
      unavailable for stories.

      However, so-called "technical stories" have a value proposition
      which is almost completely different from an ordinary story. A
      technical refactoring story may promise faster velocity sometime
      in the future, while an ordinary story is something that real
      users actually want. It is therefore very difficult, perhaps
      impossible, to compare an ordinary story and a technical story for
      value. Therefore it is undesirable to present technical stories at
      all, since they are so difficult to prioritize.

      This seems, if one doesn't think about it very hard, to be a
      dilemma. We can't take away the PO's time, we can't prioritize the
      technical stories. We can't have them at all. We are doomed.

      Like most dilemmas, this one is solved by using a third
      alternative. It turns out that [almost?] every bit of technical
      work, if it should be done at all, is done in support of one or
      more stories. IN PARTICULAR, the kind of work the OP is talking
      about, creation of tests and creation of clean code, is inherently
      part of creating stories.

      Why inherently, one might ask. Because for code to be DONE, it
      must work, and to know whether it works, we must test it. Because
      we are working incrementally, we will revisit much of the code
      many times and we might break it, so it is wise that the tests be
      recorded for reuse, i.e. automated.

      Further, since we are building the system incrementally, we are
      building the design incrementally. We do not have the time (nor,
      likely, the ability) to define the design correctly up front. We
      do not have the time to build it up front even if we did have the
      ability to define it. We must, perforce, evolve the design.
      Therefore, for each feature to be DONE, its design must be fit for
      the current purpose.

      Therefore, testing, and design improvement, are /inherently/ part
      of the work of doing stories.

      How does this help us with our dilemma? We have, through our human
      failings, fallen behind on the testing and design. What are we to
      do? We do not want to slice time away from the Product Owner. The
      Product Owner cannot correctly prioritize these strange technical
      stories. We are doomed.

      No. All we need to do is to bear down a bit on improving the code
      we work on, doing all it takes to bring it back up to the proper
      definition of DONE, namely "well-tested and well-factored". We
      make the code a bit better every time we pass through it.

      At first, maybe this takes a little longer per story. This is not
      a real concern, as no one but the team really knows if the team
      can do twelve this Sprint or only ten. The team commits to what
      they can do. They do it, and the world becomes a better place.

      Better yet, soon, surprisingly soon, it doesn't take longer after
      all. Since we are improving the code and tests in the areas we
      work in, velocity picks up quite quickly in the areas we work in.
      We wind up going faster than before, because we are going better.

      Our Product Owner retains her ability to prioritize the whole of
      our work, and our code improves. No confusion, no political
      discussion, no need to make promises about the future that we may
      not be able to keep.

      We don't need technical stories or tricky negotiations. We just do
      the job we were always supposed to do, namely make each story
      DONE, fully tested, with a good design in place.

      Ron Jeffries
      www.XProgramming.com
      Thousands of years ago, the first man discovered how to make fire.
      He was probably burned at the stake he had taught his brothers to
      light - Howard Roark (The Fountainhead, Ayn Rand)
    • Show all 28 messages in this topic