Scrum teaches us that feature requests (user stories) are to be written in the language of the customer (As <some role> I need <some feature> so that I can <get some value>.) These small sentences actually pack a load of information for the technical team reading them and it forces the user to really think about their feature and what they are trying to accomplish. All too often, even the customer doesn’t know exactly what they want, so this format helps them to succinctly describe their problem.
The beauty of the user story however is not necessarily the language or format. The user story is actually the place holder for the conversation that needs to take place. The team can then solve the user’s problem by talking through the solution with the entire team’s knowledge and wisdom at work (all the while conversing with the customer as well).
What is even more beautiful, is that Scrum provides the guide rails that help ensure the team is talking about the problem and not acting as if they are robots on an assembly line. Remember that Scrum is a framework, not a prescriptive methodology. As we go, it places guide rails to help us with our behavior and discipline.
In describing user stories, Scrum helps us to ensure we retain collaboration and teamwork. The more detail that is left out of the story, the more conversation that takes place, and the more conversation that takes place, the better the team and the solution become. Start out with the initial concept, talk about it, make notes, which then brings up other topics and considerations. Various opinions and experiences are injected and the end result should be a well-thought-out solution to a well-thought-out problem.
User stories are usually adorned with acceptance criteria (bullet points that essentially explain to the team how they know they are done). In our organization we use the words “demonstrate” on acceptance criteria to enforce the spirit of Scrum in that the done feature is demonstrable product. The point is to communicate conditions of acceptance for the story, but not eliminate the need for the developers to converse about the final solution. Too often teams can run right down the list of acceptance criteria and start coding the solution as if everything they need to know is in that acceptance criteria.
Ron Jeffries wrote a great post on “The 3 C’s” which details the heart of what we were all taking about in our last DFW Scrum Meeting. Gary McCants stated that acceptance criteria are there to guide you, but don’t let them paralyze your conversation-ability (if that is a word). Ron describes confirmation as the final deliverable to ensure we hit the mark.
Remember that the conversation takes place over time and that the user story is simply the placeholder for those conversations. Don’t write so much detail that you paralyze conversations from happening in your team.