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

Re: More newbie questions...

Expand Messages
  • Deb
    ... back ... lots of the ... important, and ... Yes, absolutely. Break it up AND choose slim sprint goals. When the users are asked to rank the more granular
    Message 1 of 33 , Aug 2, 2003
    • 0 Attachment
      --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
      <ronjeffries@X...> wrote:
      > On Friday, August 1, 2003, at 1:20:32 PM, nasapatrick wrote:
      > > Okay, so I have a backlog item like -- Derive the universe, use
      > > of paper as necessary --
      > > Which do you do?
      > > - Break it into many product backlog items?
      > > - Choose a sprint goal to implement only part of a backlog item?

      > I'd break it up, make it smaller. One advantage to this is that
      lots of the
      > subparts (make sure universe supports life) are much more
      important, and
      > some are less so (make lizards have hair).
      Yes, absolutely. Break it up AND choose slim sprint goals.
      When the users are asked to rank the more granular features, you
      might be amazed by the things they think are low priority.

      For example, when you take a project where priority rankings have
      been done inside IT (because the initial requirement was too high
      level - "derive the Universe"), and rescue it with Scrum, you take it
      back to the users and say - let's break it down and prioritise. Then
      the things that developers thought were urgent (because they are sexy
      and fun to do, or because they look good on a resume, or because they
      made incorrect assumptions about the business) - these sometimes end
      up at the bottom of the user's list! We've gotten used to automating
      just to automate, whereas the guys footing the bill, when given the
      chance, can say: "at that price, I'll keep doing it with Post-It
      notes" !

      The net result is: you can get IMPORTANT functionality out the door
      and working much faster than you could complete the whole original
      requirement. And eventually, users may drop the insignificant ones
      right off the backlog when they see that their return does not
      justify development costs.

      And, this is not "just" a newbie question. It is important because it
      hilights the essential cultural shift required by Scrum: From
      delivering the Universe because it was naively asked for, to helping
      Customers discover what they *really* want, and delivering that as
      quickly as possible.

      The heavy processes have brainwashed some developers (and managers)
      into accepting the idea that the project is a success if our delivery
      covers everything the user asked for - whether it actually meets
      their needs or not. I think the Agile movement is trying to redefine
      what successful development looks like. Success in development =
      demonstrable value for the Customer. As evaluated BY THE CUSTOMER
      (hence, active stakeholder participation). That's it! (Remembering
      that ease of maintenance is also of value to the Customer - and we
      must educate them in this).

    • Mike Beedle
      ... Christian: But in Scrum we also show what is done every day. Remember, Daily Build and Daily Scrum are basic Scrum patterns. A while ago Jeff
      Message 33 of 33 , Aug 12, 2003
      • 0 Attachment
        > From: "Christian Knott" <chrisknott@...>
        > With Scrum, we get to show what's been done every 30 days. That means
        > that the "alignment smell" gets to be put on view once a month
        > instead of, well, never in many other cases.


        But in Scrum we also show what is done every day. Remember,
        "Daily Build" and "Daily Scrum" are basic Scrum patterns.

        A while ago Jeff Sutherland pointed to an article written by
        Martin Fowler about continuous integration. All good and dandy.
        It is great to have things like Anthill produce automatic builds
        and run batches of unit tests. But it is also important for
        the Customer to interact with stable versions of the application
        and give feedback from hands-on experience on a daily basis.

        Also, there are things like Fit and Fitnesse that attempt to
        Automate "acceptance testing". Our style is to do this
        through "human interaction" -- there are some things that
        we feel are best leaving non-automated i.e. where we want humans

        In our development we have perhaps hundreds if not thousands
        of builds every day, and thousands of check ins and updates,
        but we advertise at least one stable build daily for the customers
        to play with.

        > For the specific problem of fuzzily defined requirements for reports,
        > I'm with Ron, pretty much. My difference: do something. Anything.
        > Guestimate what the report should be, do it quickly, then mark it

        Well, "mark it done" might be pushing your luck.
        Some customers take it very offensively to "mark things done"
        if they are not done. But certainly, getting a report out
        for someone to see will start the feedback loops. (Don't forget
        to update your daily estimate to completion after some work
        and feedback are produced :-)

        > The donors/owners will soon start griping, and you can convert
        > their gripes into requirements that go on the product backlog.


        - Mike
      Your message has been successfully submitted and would be delivered to recipients shortly.