The best way to build software that meets users' needs is to begin with user stories: simple, clear, brief descriptions of functionality that will be valuable to real users--User Stories Applied, Mike Cohn
Everyone loves a good story. And in Agile, part of what makes the approach simple, engaging and fun for the team is the concept of working with User Stories.
What exactly are User Stories? They are the building blocks of tasks in an Agile project. A user story is a short, concise description of the value offered by a software feature, that is explained from the end user’s perspective. The beauty of a user story is that, however complex the end product is, each user story is simple and clearly articulated, in a way that makes sense even to a layperson.
These concise descriptions speak of the ‘how, what and why’ of the product to be built, laying the foundation for the development of the product that ultimately fits user needs.
Much has been said about the three C’s in user stories—an approach to writing great user stories that transforms abstract ideas into actionable tasks. What are they, and how do they make a difference? Find out!
Telling an effective user story can be hard, even though it sounds very simple indeed. This is where the three C’s can help. Let’s find out what they are, and how they help to pin down and frame the essence of a requirement in the form of a story.
The three C’s had their origins in Extreme Programming (XP), an Agile approach to software development that follows short development cycles with frequent releases. Ron Jeffries, one of the three founders of XP, captured the components of a good user story in the 3C’s: Card, Conversation and Confirmation. Here’s what each of the Cs stands for and why they are important.
User stories are written on cards, the size of a Recipe card; approximately 3 inches by 5 inches. While originally the story was actually written on a physical card, this is not always the case now. We can still, however, use this term to refer to the optimal size of the expression of the user story.
The user story usually follows the format,
“As a [particular user], I want to [perform this action], so that [I can achieve this goal.]”
“As a Spotify user, I want to search for 90’s pop songs, so that I can make my own playlist.”
The user story as written on the card should accurately reflect the user’s needs, and should contain just enough information and no more. It should always be written in free-flowing, non-technical language that is easily understood.
Before a user story is used in a sprint, it is important that it is discussed and fleshed out in detail. This constitutes the second C: Conversation.
A conversation is a discussion between the product owner and the team. Stakeholders and business SMEs may also be present and can give their valuable inputs as well. Some user stories may be difficult to interpret, and could even require further knowledge or background before they can be implemented.
During the conversation, the user story requirement is elaborated upon and validated, and any doubts that the team may have are cleared. Questions are asked about the who, the what, and the why of the story. Thoughts and opinions are discussed, the team brainstorms, and enough detail is added to the user story to be able to prioritize, estimate and start work on it.
The third C is Confirmation, and this comprises the acceptance criteria that must be checked off to confirm that the user story has been interpreted correctly by the team and is successfully delivered. Acceptance criteria must be properly defined and documented even before development begins, so that there is no ambiguity as to whether a user story has been completed properly or not.
To minimize rework and reduce wastage of resources, these acceptance criteria are usually noted down just before the user story is pulled into a sprint backlog. Quite often in Agile, requirements change and the details will also correspondingly change. By writing down too many acceptance criteria during the planning stage, the team is leaving itself open to unnecessary rework.
Acceptance criteria for confirmation can be written in the format:
“Given [precondition], when [action] expect [result].”
“Given [an active user of Spotify], when [I choose a set of songs] then I expect [to create a playlist].”
Writing an agile user story is one of the simplest tasks that an Agile team member will have to do, and yet writing a great user story is an art that requires deep understanding and expertise to master. Most Agilists perfect their user story skills over time and with practice.
A good user story represents more than just a simple statement. With the three C’s in place, it becomes easy to capture just enough detail of the requirement in the user story, without the danger of making it too complex or difficult to get started with.
Now that we’ve given you a basic understanding of the process and the three C’s, are you ready to write your first User Story?