Step Into My Shoes
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. What is important though is that the definition of done (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 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 should 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 at the time.
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. Perhaps, even a whole new set of features and extensions.
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’ helps foresee such events.
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 accompanying use cases or storyboards. Again, these artifacts must be accessible to all stakeholders and team members. In the their absence, ‘when’ becomes all the more important.
Hi! I’m Sheldon. For over ten years I’ve worked with brands and private labels bringing some pretty awesome products to market. I’ve worked on research-based product development and marketing to deliver the total package.
I’m instantly drawn towards products that are deep-rooted in consumer research. The type that ends up being simple and intuitive, yet profound and potentially disruptive.
I’m equally passionate about brand strategy. I believe that the only thing that trumps a good product is a brand that connects with people on a deeper level.
If this resonates with you and your current need, I’d love to hear more about it.