User stories are short descriptions, usually a sentence or two, about a task one aims to accomplish. They are narrated from the perspective of the person performing that particular task. A user story provides a good understanding for ‘how’ and ‘why’ a feature is important to him/her. A typical template reads:
As a <user type >, I want to < aim > so that < reason >
Before going deeper into what makes a story more meaningful, let’s discuss a few characteristics relevant to them.
How Does A User Story Help The Team?
User stories are meant to inspire collaboration, understanding and creative solutions. They present an opportunity for the entire team to engage in constructive discussions on how to best serve a user’s needs.
When Are User Stories Written?
Stories are written throughout the agile process. Through continuous learning and feedback, new stories emerge and are added to the product backlog. This ensures that the product evolves as more information finds its way back.
How Small Should A Story Be?
Typically, user stories are small enough to be accomplished within a given sprint (1-4 weeks). Each story would then entail a set of tasks that must be completed in order for the story to be addressed appropriately.
Definition Of Done
User stories are not ‘done’ unless they are coded, tested and documented. But, in the agile world, the definition of done (DOD) varies. What is important though is that the DoD checklist is agreed upon and shared by everyone on the team at the beginning. This ensures that quality is injected into the build and that it is worthy of being released.
What Level Of Detail Is Necessary?
Good stories provide just enough information to indicate why a particular feature offers a user value. It should offer sufficient clarity for the development team to understand its significance from the user’s point of view.
There should not be any doubt or misinterpretation as the feature gets developed. Stories must be unambiguous, complete, on point, non-conflicting, and easily understood by anyone, even those not directly connected with the project.
Should User Stories Replace The Feature Requirement Document?
User stories provide more depth to an ordinary requirement document. They answer questions that are inherently absent in requirement documents. For instance, they provide contextual drivers behind the feature. Feature requirement docs are great for reference purposes, but user stories go the extra mile.
Shortcomings Of User Stories
- Reduced contextual understanding.
- May not fully account for all possibilities or scenarios faced by the user.
What I’d Like To See More In User Stories
I personally feel that when situational elements are incorporated, they can further energize a user story. A simple story includes ‘who’ wants ‘what’ and ‘why’, but, adding situational elements introduces ‘when’ into the equation. With this component, we have the potential to develop features accounting for more context. There can be situational influences that warrant a slight deviation.
Businesses are constantly encountering change in the environment in which they operate. Special circumstances that are rare but possible may need a hard-coded process to be a little flexible. These user stories may not surface as they are the exception and not the norm. Adding ‘when’ delivers a bit more clarity.
Situational elements are useful when indirect stakeholders and new team members aren’t intricately familiar with the user’s role, scope or work conditions. These can be incorporated into the user story as follows:
As a <user type >, I want to < aim > so that < reason >… This feature is important to me <when>.
In addition it is good practice to add numeric or alphanumeric markers to user stories so that they are traceable to use cases or storyboards. These artifacts must be accessible to all stakeholders and team members. In the absence of use cases and storyboards, ‘when’ becomes all the more important.