A user story is a tool used in Agile software development to capture a description of a software feature from an end-user perspective. The user story describes the type of user, what they want and why.
The most common format for writing User Stories is “As a (role) I want (feature or capability) so that (business value to be delivered)”.
The key to writing good User Stories is collaborative development of the User Stories through discussion amongst the entire project team. This requires dedicated resource allocation to recurring workshop meetings for all team members.
The generally accepted User story concept follows a decomposition approach. The decomposition comes in the form of a story map. The beginning of a story map is defining the Backbone stories – the key User Activities or Tasks which need to be accomplished to do the work of the system, the large discrete chunks of functionality which need to be delivered to be able to say we have solved the problem. These large chunks are often referred to as Epics. In a Waterfall methodology, these would represent the Business or User Requirements.
When building a story map, these Epics are normally laid out in a single row showing the logical sequence and handoffs between the steps in the process. Visually these Epics will be written on a different color card than the User Stories, which will come later.
Here is an epic agile user story example from a desktop backup product:
“As a user, I want to backup my entire hard drive on demand to avoid loss of data.”
The next step in the Story Map is to populate the map with the User Stories that fall under the Epics. Each User Story is a small, discrete piece of functionality that has value to some user of the product and is a decomposition of the Epic above. User Stories include the level of detail that would be specified in a System Requirement for a Waterfall methodology.
The Epic above could be split into dozens (or possibly hundreds) of User Stories, including these two:
“As a power user, I can specify files or folders to backup based on file size, date created and date modified.”
“As a user, I can indicate folders not to backup so that my backup drive isn’t filled up with things I don’t need saved.”
One of the benefits of building a Story Map is that it shows the logical flow of activities (from Epic to Epic along the top) and the discrete elements of those Epics vertically down the page. This allows us to clearly see both sequence and priority. Stories that are higher up on the map are more important (needed sooner) than those lower down.
It’s important to note that as user stories are better defined, more user stories may be added, some may be dropped and our understanding of many will change as time progresses.
A user story has three basic elements; which can be referred to as the three C’s: the Card, the Conversation and the Confirmation.
The Card is the initial user story which is deliberately short and devoid of detail. The intent is to defer the detail until later in the project, just ahead of when this piece will be delivered.
The detail is established through the second C – Conversations. As the project progresses and elements are delivered there will be a number of conversations that result in clarity of understanding about what is actually needed to deliver the value identified in the User Story.
The final C is Confirmation – these are the Acceptance Criteria for the user story – the details which will enable the customers and the technical team to agree that “if this story meets these criteria it is done”. This is the detail which is all too often left out in Agile projects. This detail needs to be agreed to, and it will contain whatever is needed to enable the delivery of this component of the system.