This post originated from an RSS feed registered with Agile Buzz
by Martin Fowler.
Original Post: ConversationalStories
Feed Title: Martin Fowler's Bliki
Feed URL: http://martinfowler.com/feed.atom
Feed Description: A cross between a blog and wiki of my partly-formed ideas on software development
Here's a common misconception about agile methods. It centers on
the way user stories are created and flow through the development
activity. The misconception is that the product owner (or business
analysts) creates user stories and then put them in front of
developers to implement. The notion is that this is a flow from
product owner to development, with the product owner responsible for
determining what needs to be done and the developers
how to do it.
A justification for this approach is that this separates the
responsibilities along the lines of competence. The product owner
knows the business, what the software is for, and thus what needs to
be done. The developers know technology and know how to do things,
so they can figure out how to realize the demands of the product
owner.
This notion of product owners coming up with
DecreedStories is a profound misunderstanding of the way
agile development should work. When we were brainstorming names at
Snowbird, I
remember Kent suggesting "conversational". This emphasized the fact
that the heart of our thinking was of an on-going conversation
between customers and developers about how a development project
should proceed.
In terms of coming up with stories, what this means is that they
are always something to be refined through conversation - and that
developers should play an active role in helping that
definition.
spotting inconsistencies and gaps between the stories
using technical knowledge to come up with new stories that
seem to fit the product owner's vision
seeing alternative stories that would be cheaper to build
given the technological landscape
split stories to make them easier to plan or implement
This is the Negotiable principle in Bill Wake's INVEST test for
stories. Any member of an agile team can create stories and suggest
modifications. It may be that just a few members of a team gravitate
to writing most of the stories. That's up to the team's
self-organization as to how they want that to happen. But everyone
should be engaged in coming up and refining stories. (This
involvement is in addition to the develpers' responsibility to
estimate stories.)
The product owner does have a special responsibility. In the end
the product owner is the final decider on stories, particularly
their prioritization. This reflects the fact that the product owner
should be the best person to judge that slippery attribute of
business value. But having a final decision maker should never stop
others from participating, and should not lead people astray into a
decreed model of stories.