I'm working with a large client that has adopted the classic user story format for the backlog.
Yet, I'm sure that it is not delivering the desired shared understanding that throwing out the classic business requirements document and adopting the scrum/XP user story practice is designed to deliver.
So if your groups user stories have become just a piece of boiler plate language to satisfy some agile coach's requirement - maybe you should reflect upon the desired reason for user stories rather than requirements documentation so many years ago. User stories do work. But you have to tell a story. Few authors are good enough to tell a story in one sentence.
Here Ron is pointing to one of the XP practices that were very successful in replacing the big upfront requirements documents with the concept of stories. In XP this was the Card-Conversation-Confirmation technique. In this technique the card and the label or title written upon the card is the place-holder used in planning. In this way the card becomes a token for the planning game (XP practice similar to Scrum's Sprint planning). The Conversation is the part of the practice that may be missing if your groups don't find the one sentence description (in classis form) to be sufficient to plan, estimate, design, develop, test, and deploy the user story.
Another group behavior that I've noticed is that the Confirmation aspect of these user stories may be a bullet point list of statements that are not recordings of a dialogue (as described in Ron's XP article). To improve efficiency of requirements gathering some groups have people working independently and ahead of the development teams to write user stories and acceptance criteria. This practice can sometimes improve communication and sometime harm the shared understanding that is required for highly productive development teams. In the C-C-C technique of XP the team and the customer wrote the confirmation statements together, a technique for validating that a shared understand had been reached during the conversation. This also served as reminders during their demo of the application behaviors that would be observable with working software.
Learn to Tell the Story
The common reframe today is the distinction between telling stories and writing stories. Which is your team doings? We all are much better at telling stories than at writing stories - it's just how much individuals practice telling stories. We start at the early age of 3 or 4 and continue to practice for our entire life. Few of us actually practice writing stories. Can you see the powerful distinction between these two practices?
When telling stories a great practice is to have one or more people capturing the important points and themes as the teller spins the tale of the feature and the value it will bring to your customers.
A higher level abstraction from telling stories occurs in the Story Mapping practice as described by Jeff Patton - Story Mapping is a better way to work with Agile User Stories.
"User Story Mapping is a dead simple idea. Talk about user’s journey through your product building a simple model that tells your user’s story as you do. But it turns out this simple idea makes working with user stories in agile development a lot easier."
The behavior of teams that are being helped by the practice of writing detailed user stories is quite different than the behavior of teams that are being harmed by the practice. The great thing about Scrum is that this difference should become apparent in a short amount of time - say one or two sprints. When the shared understanding is being communicated by the written story and the conversation and the team is delivering working tested software that meet the confirmation aspects (acceptance criteria) of the story then one can easily observe the behavior in the demonstration of the working application each sprint. If that is not happening, then perhaps the story is not being communicated, there is more to a great story than just one little sentence.
You also may want to reconsider the format of the classic user story - because they lack the obvious title that all great stories must have. Try this alternative format:
See Also:
Definition of Done vs. User Stories vs. Acceptance Criteria by Mark Levison of Agile Pain Relief a consultant with lot's of wise content and great practices to teach.
Names should not be needed for user stories - by Mike Cohn
Advantages of the As a User I want - user story template - by Mike Cohn
User Stories Applied - book at Amazon
10 Tips for Writing Good User Stories - Roman Pichler
Good Stories have Great Titles - Lance Kind
6 Brilliant ways to slice user stories by Dominic Krimmer
** Telling User Stories vs Writing User Stories **
A Story About User Stories - The real intention behind user stories - by Ebin Poovathany
Focus on telling user stories - Charles Bradley
Story Mapping concepts (PDF) by Jeff Patton
"As a user, I want some feature so that I receive this benefit."
Yet, I'm sure that it is not delivering the desired shared understanding that throwing out the classic business requirements document and adopting the scrum/XP user story practice is designed to deliver.So if your groups user stories have become just a piece of boiler plate language to satisfy some agile coach's requirement - maybe you should reflect upon the desired reason for user stories rather than requirements documentation so many years ago. User stories do work. But you have to tell a story. Few authors are good enough to tell a story in one sentence.
@davidakoontz @dayleyagile
Card, Conversation, Confirmation. Card contents irrelevant.
http://t.co/IIUdJJmxA1
— Ron Jeffries (@RonJeffries) May 15, 2014
Here Ron is pointing to one of the XP practices that were very successful in replacing the big upfront requirements documents with the concept of stories. In XP this was the Card-Conversation-Confirmation technique. In this technique the card and the label or title written upon the card is the place-holder used in planning. In this way the card becomes a token for the planning game (XP practice similar to Scrum's Sprint planning). The Conversation is the part of the practice that may be missing if your groups don't find the one sentence description (in classis form) to be sufficient to plan, estimate, design, develop, test, and deploy the user story.
Another group behavior that I've noticed is that the Confirmation aspect of these user stories may be a bullet point list of statements that are not recordings of a dialogue (as described in Ron's XP article). To improve efficiency of requirements gathering some groups have people working independently and ahead of the development teams to write user stories and acceptance criteria. This practice can sometimes improve communication and sometime harm the shared understanding that is required for highly productive development teams. In the C-C-C technique of XP the team and the customer wrote the confirmation statements together, a technique for validating that a shared understand had been reached during the conversation. This also served as reminders during their demo of the application behaviors that would be observable with working software.
Learn to Tell the Story
The common reframe today is the distinction between telling stories and writing stories. Which is your team doings? We all are much better at telling stories than at writing stories - it's just how much individuals practice telling stories. We start at the early age of 3 or 4 and continue to practice for our entire life. Few of us actually practice writing stories. Can you see the powerful distinction between these two practices?
When telling stories a great practice is to have one or more people capturing the important points and themes as the teller spins the tale of the feature and the value it will bring to your customers.
 |
| User Story Mapping |
"User Story Mapping is a dead simple idea. Talk about user’s journey through your product building a simple model that tells your user’s story as you do. But it turns out this simple idea makes working with user stories in agile development a lot easier."
The behavior of teams that are being helped by the practice of writing detailed user stories is quite different than the behavior of teams that are being harmed by the practice. The great thing about Scrum is that this difference should become apparent in a short amount of time - say one or two sprints. When the shared understanding is being communicated by the written story and the conversation and the team is delivering working tested software that meet the confirmation aspects (acceptance criteria) of the story then one can easily observe the behavior in the demonstration of the working application each sprint. If that is not happening, then perhaps the story is not being communicated, there is more to a great story than just one little sentence.
You also may want to reconsider the format of the classic user story - because they lack the obvious title that all great stories must have. Try this alternative format:
<What I Want>This format creates a nice handle or title in the "What I Want" phrase.
so <Role> can <Business Value>
See Also:
Definition of Done vs. User Stories vs. Acceptance Criteria by Mark Levison of Agile Pain Relief a consultant with lot's of wise content and great practices to teach.
Names should not be needed for user stories - by Mike Cohn
Advantages of the As a User I want - user story template - by Mike Cohn
User Stories Applied - book at Amazon
10 Tips for Writing Good User Stories - Roman Pichler
Good Stories have Great Titles - Lance Kind
6 Brilliant ways to slice user stories by Dominic Krimmer
** Telling User Stories vs Writing User Stories **
A Story About User Stories - The real intention behind user stories - by Ebin Poovathany
Focus on telling user stories - Charles Bradley
Story Mapping concepts (PDF) by Jeff Patton
Comments