User Story – not a very fancy term, right? Well, it doesn’t need to be, because it is a simple concept that a lot of “Agilists” misunderstand, and hence misuse. I see a user story as a simple description of the work that has to be done in order to make some progress in delivering the end product, that the team is working towards delivering.
To shed some more light on this topic, I will explain here how I have used them over more than a decade and what has been working for me.
For better management, I categorize all my user stories under the following 4 types of work items:
(1.) GREEN – Development stories: These are the work items that require some code to be written, reviewed by a peer, tested and bug-fixed. It is good practice to prefix the title of such stories with tags like: “Dev”, “Green”, “Create” etc.
(2.) ORANGE – Spikes or Research stories: Any work items that require some technical research before writing the code, or even before testing the code are categorized under this bucket. It is good practice to prefix the title of such stories with prefix like: “Spike”, “Research”, “Investigate” etc.
(3.) PINK – Bug fixes: As the name suggests, these stories are used to write code towards fixing any known bugs in the system. Often teams confuse this category with bug fixes for the ongoing development (green) user stories. Any bug fixes for the planned development user stories are part of those stories themselves and are not to be allocated under this category.
(4.) BLUE – Support stories to other team or projects: User stories for any support being provided to any outside team/project.
3 key components, that I use in any user story are the 3Ws: “who, what and why?”
- who – is the user of the functionality being built as part of the user story.
- what – is the action or intention of the user story.
- why – is the business value to be achieved / an explanation of why the story is needed.
The above 3 components together constitutes what is referred as “Acceptance Criteria” of the user stories. Here is the typical (recommended) format, that I use to create user stories:
- As a <user>, I should be able to <action>, so that <business value>.
- As a <who>, I should be able to <what>, so that <why>.
Examples:
- As a patient, I should be able to login into the my patient portal account, so that I can access my billing information.
- As a doctor, I should be able to login into patient’s account, so that I can view his/her medical history.
Here are a few key components of any user story:
- Title: A single line short description of the user story.
- Acceptance Criteria: The detailed description of the user story that explains the 3Ws (described above) – who, what and why. This also includes any added details, such as detailed descriptions, attached documents, screen shots, mockups, work flows etc. A story is truly considered Done, if this criteria is met. This is more like a contract between the product owner and the team.
- Story Points: This number attached to the user story is a measure of complexity or how difficult a story is to implement. I mostly use fibonacci series (1,2,3,5,8…) to estimate user stories.
- Assigned to: This is the team member who is responsible for the completion of the story. Since agile teams are supposed to be self-managed and self-organizing, it is the team that owns the story. “Assigned to” field is typically to refer the main owner of the story.
- State: These are various conditions a story typicall flows through, from its inception to completion (achieving the done-done state).
Here are the common states a user story goes through in its lifecycle:
- In Backlog – this is when the story sits in the Product or the Sprint backlog.
- Requested – this is when the story has been planned to be completed in the sprint.
- In Development – this is where the story is being coded.
- In Code-Review – this is where the code is reviewed by a peer to ensure it meets the set coding standards and best practices.
- Requested In Testing – this is where the QC team tests the functionality to ensure it meets the acceptance criteria.
- In Systems Integration Testing (SIT) – this is where the system as a whole is tested to ensure that the story has not broken the system.
- Complete/Done – this is the state, where the team has completed the work and the story is ready to be accepted by the PO.
- Accepted – this is where the story has been accepted by the PO, post the demo to the stakeholders.
- Released/In Production – this is where the story is released to an end environment, typically staging or production, as per the team’s agreement.
Breaking your stories in line with the above states and moving them as per these states in your daily boards, can help your teams get more visibility, and provide the needed transparency to the stakeholders.
I hope this article helps you understand the concept behind user stories and how to use them. Enjoy and keep learning!