This post originated from an RSS feed registered with Agile Buzz
by Simon Baker.
Original Post: How we use stories
Feed Title: Agile In Action
Feed URL: http://feeds.feedburner.com/AgileInAction
Feed Description: Energized Work's blog.
All our work items, both user-focused and technical, are stories framed in the context of a user interacting with the product. Each story represents a distinct, visible and testable piece of work that can be delivered independently to realize some value. Stories exist at many levels of specificity and never convey solutions. For example, at a point in time it's sufficient to use an ambiguous story to describe an interaction as simply an activity a user engages in using the product. At some time later, typically when detail starts to matter, smaller stories are written to describe that activity in terms of more specific tasks the user performs with the product.
Stories are written on index cards measuring 6 by 4 inches. A description of the user interaction is written in as few words as possible on the front of a card to provide a brief outline. This provokes conversations to reveal and understand the details, which are captured as acceptance criteria on the reverse side in the language of the user. The physical card serves as a token, exchanged amongst the team when different people work on the story. It also acts as a physical flag that shows others what's in progress and a story's history in terms of the feedback obtained so far from testing, user experience, etc. Different colored index cards are used for different types of user:
1. Business and end users
White cards describe stories written for business and end users.
Green cards describe user experience stories that need to be completed ahead of time and in just enough detail, e.g. using low fidelity prototypes or design mock-ups, to facilitate an iterative approach and provide useful input to the corresponding white cards.
Pink cards describe defects from the users' perspective and include the steps to reproduce on the back. We never debate whether something is a defect or not, we just ask the product owner.
2. System and technical users
Yellow cards describ stories written for technical users, e.g. a system administrator operating and supporting the product, or for discrete system engineering work such as scalability and resilience.
3. Technical debt
Blue cards describe stories written for developers, who are considered users of the system at an engineering level. They describe technical debt in system and software terms and include acceptance criteria on the back so the developers know when they're done.
The size of a story isn't important until it's planned and prepared, ready to be implemented.
Developing the product iteratively
Using iterative development we progressively refine and extend functionality already delivered. Over time a user task is sometimes revisited by any number of stories. Whenever possible we use a green card to build a paper prototype that allows us to evaluate interaction designs with users before developing any software. The first white card typically delivers very basic functionality that allows users to perform the task using the product. Feedback from users validates our assumptions and often initiates a new story to enhance the functionality or improve its performance and ease of use. Every story aims to improve the experience for the user based on their feedback to enable them to perform the task more efficiently or effectively.
By delivering a minimal version of functionality early and then evolving it in response to user feedback, we remain receptive to discovery and keep our options open rather than committing prematurely to a specific user experience. This way we invest more wisely to deliver exactly what the users wants, and no more.
Previous Topic
