User stories are a lovely manifestation of “individuals and interactions over processes and tools”. The team and the stake holder get together and have a conversation where a story about a need is told. The ensuing conversation helps create understanding and clarity. User stories facilitate collaboration, and create a shared clear understanding of what is really needed between customer representatives and development teams in a fast and economical way. Originally an artefact from eXtreme Programming (XP) user stories are now a part of most agile methodologies.
Unfortunately somewhere along our journey towards agile maturity we seem to have forgotten about the “story” part of user stories. Agile coaches love to teach the so called “3Cs” of user stories, Card, Conversation, and Confirmation and yet a common problem I have observed multiple times with many teams is that we have forgotten about the conversation. It seems the product owner writes the user stories and just drops them onto the team. There is very little of the collaborative writing and revision that fosters understanding. The promise for the conversation seems to have been broken.
This processes and tools approach to user stories is common when the product owner/customer representative is geographically separated from the team (e.g off shore development team). The lack of a conversation – the lack of interaction between individuals – now means heavyweight processes and tools are needed to communicate what could have been understood in a simple conversation. I have seen user stories where the acceptance criteria were 6 pages of psuedo code. All this did was push the cost of development up stream from the off-shore development team to the business analyst writing the user story. Worse, it dramatically slowed the decision making process and the cycle time. These are the real economic cost of trying to save money.
As agile coaches we have to share some responsibility for this. Many development problems are traceable to “poor” user stories and our typical solution as coaches is to emphasize well formatted user stories….those that meet the INVEST criteria, those written in the “As-a, I want, Such that” format popularized by Mike Cohn. We chastise those who do not write “high quality” acceptance criteria. However, high quality user stories are not a proxy for understanding. Are we failing to ask the questions, do these stories create a shared clear understanding of what the need is? Are they still a manifestation of “individuals and interactions” or have they become “processes and tools”?
As product owners, as business analysts, as developers and as coaches we need to put the story back into user story. Not break the “promise for a conversation” but embrace the individuals and interactions that co-write the user stories that creates the shared clear understanding of what the need really is. The first time a team sees a user story must not be the iteration or sprint planning meeting. For without the story, there is no user story.