User stories are the currency of value in an agile development environment. They not only are the focus of estimation, sprint planning and other team activities, but are also important in ensuring that teams are delivering customer-driven value.
User stories serve as a framework for conversations about a particular functional slice of value. User stories give these abstract ideas a sense of reality so they can be discussed within the team. They also give us the criteria for evaluating the result of value-driven efforts. It is important to construct stories so that they can be continuously improved and subsequently executed with clear evidence of the achieved value.
As with many other aspects of agile and lean development practices, we don’t bother pretending that we know everything or that we can get everything right on the first try. The same attitude should be used when creating and refining your user stories. Don’t try to write a perfect story when you are developing your story ideas. Use an iterative approach to build up your stories from simple language.
The Three C’s approach to story writing is a great way to kick off the process that anneals abstract ideas into concrete, workable user stories. The process allows us to start with a simple idea as a seed to germinate a more usable story by making small, incremental changes.
The first C is "CARD"
The idea is written on a card or a sticky note and starts off as a "draft story". As a team, we can go through an exercise of just coming up with the titles of stories first and then adding more detail iteratively. If you feel that your stories will be changing a lot, don’t be afraid to use a whiteboard.
Now we have a little something to work with that everyone on the team should immediately understand. This will give us the groundwork to start refining our idea into a good quality story.
We should make an effort to re-write our story in "user voice" format. This helps us maintain a uniform vocabulary among stories to make discussion more consistent and productive.
Remember that user stories should be written as a negotiable statement of value and intent from the perspective of the actor that is receiving the value or initiating the value process. This is called ‘user voice’ and is much more effective in communicating ideas about value. We use natural, non-technical language to detail the value proposition.
The "Role" describes who is receiving value, the "Action" describes how the flow to value is initiated, and the "Value" describes the desired outcome. We can then reword our ideas into the narrative of the user story:
If you are discussing a complex idea, and the narrative of the user story does not easily translate to user voice, then try to work with what you have. Don’t be afraid to walk away from a complex story to give your team time to ponder it, or break it down to less complex stories. Come back after you have spent some time thinking about something else, and try to add just a little more information each time. This is a much more team-friendly approach than over-discussing a complex story. Remember the goal is to add value to our product in increments—we can use the same principle on our user stories.
Many agile tools will allow you to give a short title for a story and then fill in the details as a description. This allows you to create placeholders for stories and iteratively add to the description as the information about the story becomes clearer.
The second C is "CONVERSATION"
From the initial idea, we can start having discussions between the team and the product owner to formulate the questions that will be used to drive down to the details of the story. We ask questions primarily about the WHO, the WHAT and the WHY of the story and focus on the WHEN and HOW later in the process. We might end up with a list of questions that will eventually become part of the story itself.
The product owner’s responsibility is to answer these questions as a condition of the story being ready to plan. As part of your grooming process, it is a good idea to revisit and update the story if there are any open issues that need to be similarly resolved.
The third C is "CONFIRMATION"
As these questions are answered, we start to see that they are the basis for the development of the acceptance criteria for the user story. These are the mechanisms for determining the technical details of the story as well as to confirm that the implemented story is delivering the intended value.
As with the narrative of the user story, it is efficient to maintain some consistency among acceptance criteria. This can be achieved using this formula:
Now we can build a list of the acceptance criteria we have created for our story:
It is essential to remember that good user stories are not born that way. The best stories are those that are continually groomed and improved during their lifetime in your team’s backlog. Although grooming ceremonies are an important part of some teams’ agile regimen, all team members should always be mindful of new ways of looking at value to ensure that stories are relevant, complete and easy to understand and execute.
Don’t spend too much time on a story. Go on to another story and work on it a little bit, then come back and refine it a little each time. Cycle through the stories at the top of your backlog and improve each incrementally every time you discuss it. You might find yourselves ready to do a preliminary estimate, or even improve your estimation with each pass through the backlog. Once your top stories have reached their "definition of ready", you are ready to plan them into a sprint.
Where are you and your company in your agile journey? Can you make it happen internally, or do you want experienced coaches to guide you along your journey? Summa’s agile practice can help your company achieve success in transforming into a high-performing organization. For questions about the Three C’s, User Stories, Acceptance Criteria or anything else regarding lean/agile practices, please reach out to us at agile@summa.com.
