18598Re: Scrum illness, symptoms and possible treatments
- Dec 31, 2006Hi 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 email@example.com, "Clinton Keith" <ckeith@...>
>teams when those things need attention?
> Who is reponsible for tracking the checklist and communicating to the
> -----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"done".
> 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"shipped"
> column on the story board.example,
> 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:keep
> - 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.
- << Previous post in topic Next post in topic >>