Stories
Note
Whole Team
We plan our work in small, customer-centric pieces.
Stories may be the most misunderstood entity in all of XP. They’re not requirements. They’re not use cases. They’re not even narratives. They’re much simpler than that.
Important
Stories are for planning. They’re simple one- or two-line descriptions of work the team should produce. Alistair Cockburn calls them “promissory notes for future conversation.”[38] Everything that stakeholders want the team to produce should have a story, for example:
“Warehouse inventory report”
“Full-screen demo option for job fair”
“TPS report for upcoming investor dog-and-pony show”
“Customizable corporate branding on user login screen”
Important
This isn’t enough detail for the team to implement and release working software, nor is that the intent of stories. A story is a placeholder for a detailed discussion about requirements. Customers are responsible for having the requirements details available when the rest of the team needs them.
Although stories are short, they still have two important characteristics:
Stories represent customer value and are written in the customers’ terminology. (The best stories are actually written by customers.) They describe an end-result that the customer values, not implementation details.
Stories have clear completion criteria. Customers can describe an objective test that would allow programmers to tell when they’ve successfully implemented the story.
The following ...
Get The Art of Agile Development now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
