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

18598Re: Scrum illness, symptoms and possible treatments

Expand Messages
  • Mike Bria
    Dec 31, 2006
      Hi Clint --

      Well, in most cases its just the team's responsibility to "play by the

      What's often done within the team is a "story sale", which means this:
      As soon as (or before) a story is chosen to be developed by a programmer
      (actually, a pair in our case), one non-developer team member (usu. a
      business analyst, ui designer, or something of the like) also signs up
      as the "buyer". When the pair thinks they're done with the story, they
      stand up and say,"hey, story for sale!", at which point everyone around
      (at least the "buyer") sits down for a demo where the feature will be
      played with (ie, integration testing), programmer/customer tests will be
      shown to run, etc. Basically, it's the job of the "buyer" to "track the
      checklist" and make sure the t's are crossed. If not, they don't "buy"
      the story and the pair goes back to work.

      All this said, admittedly, for this to really to be of much help there
      needs to be some sense of responsibility within the team. Even in the
      absence of that though, at least the checklist provides some common
      ground come review time for the Product Owners to look to and somewhat
      objectively say hey "we kinda all agreed you would have done x, y, and
      z. Can we talk about why z isn't really done?"

      One subtle, yet important, side effect (and one that may possibly apply
      in you situation) is that this activity helps to bring the "people of
      different disciplines" [programmer, "buyer", etc] together to increase
      not only the overall communication within the team, but more-so the
      sense of "shared responsibility" (collective ownership) to the quality
      and completeness of the product being delivered.

      Sorry for the windy response, I hope it might help a bit though. Here's
      to a spectacular 2007!..

      --- In scrumdevelopment@yahoogroups.com, "Clinton Keith" <ckeith@...>
      > Mike,
      > Who is reponsible for tracking the checklist and communicating to the
      teams when those things need attention?
      > Clint
      > -----Original Message-----
      > From: Mike Bria
      > Sure. Similiar to Clint, my situation is one with many scrums all
      > working on the development of basically one enterprise level product.
      > With the somewhat increased challenges related to system integration,
      > documentation, integration testing and other product-wide items that
      > exist due in large part to our scale, we've found that it's very
      > to have a documented "DONE" checklist that levels expectations across
      > the teams as to what it means for a Story to be, as you'd guess,
      > In other words, what you need in order to move the card to the
      > column on the story board.
      > It's really nothing fancy, it mostly includes the things that seem
      > natural to most, things related to testing, documentation (of the
      > end-user type that is), upgrade support if needed, etc. So for
      > it might look like this:
      > Are...
      > - all programmer tests passing?
      > - all customer tests passing?
      > - all function-level integration tests verified?
      > - your related user-docs up to date?
      > - your data upgrade scripts written and tested (if applicable)?
      > - your managers buying you beers for being so dang good?
      > Te real benefits are the things that end up on the list because of
      > something specific to your environment or to a particular release that
      > isn't "standard Scrum/XP business as usual".
      > It's just one more thing posted up in the "open workspace" to help
      > everyone thinking about the same general product goals and operating
      > under the same basic standards.
      > Cheers...
      > --MB
    • Show all 18 messages in this topic