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.
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.” 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”
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 ...