User stories are short descriptions, usually a sentence or two, about what one aims to accomplish as told from the perspective of a user. They help focus on a contextual understanding of ‘how’ and ‘why’ a feature is important to a user. A typical template would read:
As a <user type >, I want to < aim > so that < reason >
Before I discuss what I feel makes user stories more meaningful, let’s answer a few general questions relevant to user stories.
How do user stories help?
User stories aren’t meant to simply replace a feature document. They are meant to inspire collaboration, critical thinking and creative solutions. User stories, being somewhat contextual, present the opportunity for the entire team to engage in constructive discussions on how best to deliver value to the user.
When are user stories written?
User stories are written throughout the agile process. In fact, they never end. Through continuous learning and feedback, new stories are drawn up and added to the product backlog ensuring that the product evolves in relation to the environment.
How small should a story be?
Typically, user stories should be bite sized so that they can be accomplished within a given sprint. Higher level stories, called epics, provide a bird’s eye view of the user’s problem. They must be broken down into more manageable lower level stories for the team to work on. Each story would then entail a single task or set of tasks that must be completed in order for the story to be considered ‘done’. It is possible, based on the level of complexity, for several sprints to occur before that is possible and a releasable iteration available.
What level of detail is necessary?
Good user stories provide just enough information to indicate why a particular feature offers user value. It gives sufficient clarity and context to the development team so that they understand it’s significance from the user’s point of view. The best way to add detail to user stories is to either create sub-stories or list a set of conditions and requirements for each story.
Should user stories replace the feature requirement document?
User stories provide more depth to an ordinary feature requirement document. It answers questions that are inherently absent in feature docs. Let’s consider product packaging for a moment. Today most packaging talks about the benefits of the product in an easy to comprehend language. Had they been written in non-empathetic technical terms, many users wouldn’t fully grasp the possibilities on offer. The same applies to the development team. Feature requirement docs are great for a quick listing / reference purposes, but user stories provide more insight.
What I’d Like To See More Often In User Stories
While the information provided above is good to get anyone started in user stories, I personally feel that when personas and situational elements are employed, they can further energize the story. Personas add more detail about ‘who’ the feature is being built for. It could potentially tell us about the demographics, psychographics and behavioral aspects of our users. This leads to more user-centric products. Of course, a lot depends on the level of intricacy needed by the team.
Situational elements add even more context to the story. A simple user story includes ‘who’ wants ‘what’ and ‘why’ but adding situational elements introduces ‘when’ into the equation. Armed with these two components, we have the potential to develop features that are more ‘thought-through’ and welcoming than the competition.