Seb Rose explores what a good user story should look like, discussing why many of them fail to live up to people's expectations.
Seb Rose has been a consultant, coach, designer, analyst and developer for over 30 years. He is a regular speaker at conferences and occasional contributor to software journals, a contributing author to “97 Things Every Programmer Should Know” and lead author of “The Cucumber for Java Book”.
Agile Tour London is an annual conference which explores all aspects of agility and its adoption and implementation in a business environment. Packed with inspirational talks and hands-on workshops, Agile Tour London 2016 offers unmatched opportunities to learn from the best agile experts in the industry. Whether you are an agile newbie or been in the industry for years, this is the definitive agile conference you can't afford to miss.
Make Your User Stories Riveting
I've watched two of your presentations
1) Make Your User Stories Riveting
2) BDD by Example - Agile on the Beach 2014
Did I get something wrong or do you suggest that we throw out user stories or was that just the original idea ? Because for me it seem s to be orthogonal to the concept of living documentation that you touch on in BDD by example. Namely that user storeis becomes implemented acceptance tests, that again becomes living documentation which is up to date with the actual implemented system.
Re: Make Your User Stories Riveting
When stories were first used, back in the day, they were described as "a placeholder for a conversation." They were a way of deferring detailed analysis until we were fairly sure that we were about to implement a particular piece of functionality. The expected output of the conversation was the detailed requirements for the functionality which we were about to implement, spread over one or more smaller user stories. These smaller, detailed user stories' purpose is to allow us to prioritise and plan the delivery of the functionality in small increments.
The way this process maps to the living documentation is that the requirements (a.k.a rules a.k.a. acceptance criteria) are captured at the top of a Gherkin feature file. The concrete examples are captured in formulated scenarios. The user stories themselves are no longer valuable, especially since many of them will have been very thinly sliced, "low-fidelity" stories. Each story builds upon those already delivered, making stories unsuitable for long term documentation.
There was a time when every iteration ended with a "confetti party". All the user story cards that had made it to the DONE column were torn into small pieces and thrown up in the air, to the delight of the team. It was a long time ago. We were easy to please ;)