Say What, Why, and for Whom Before How in order to describe goals and constraints, not implementation details. Say what to build but don’t say how to build it; let developers discover the how and abstract the how with the what. This helps hide implementation details so code is simpler to work with and less costly to extend. When stories replace requirements and development becomes discovery, we build a better product than if we’d tried to figure it out up front.
In this chapter, we discovered…
By focusing on what the software should do instead of how it should be done, developers are free to discover the best implementations.
To build better-quality software, you need to know how to communicate with the people around you.
Shifting the crucial conversation for defining features from describing implementation details to describing what, why, and for whom helps development become a discovery process.
Effective Product Owners write good stories with clearly defined acceptance criteria.
Build features more effectively to reclaim up to a third of all time spent in development, eliminating written requirements and building a creative collaboration between the Product Owner and the development team.
Teams that change the way they define features from describing implementation details to saying what, why, and for whom the feature is can reclaim up to a third of development time by eliminating written requirements and starting a creative collaboration between the Product Owner and the development team.
Cockburn, Alistair. “A user story is the title of one scenario whereas a use case is the contents of multiple scenarios.” http://alistair.cockburn.us/A+user+story+is+the+title+of+one+scenario+whereas+a+use+case+is+the+contents+of+multiple+scenarios/v/slim