A user story is related to agile software development methodology, it describes a product’s features from an end user’s point of view. Agile user stories include a series of conversations about a product’s desired functionality.
Product managers can easily describe software requirements through user stories, making it easy for the development team to comprehend the desired result. An amazing user story template talks about the ‘who’, ‘what’, and ‘why’ of a product feature effortlessly. It is written in an easy-to-understand business language to explicitly convey the wants of the end-users. Most of the agile user stories comprise one or two written sentences, followed by a sequence of conversations linked with the desired functionality.
User stories usually follow a simple template. The basic user story outline can be in the following format:
As a (user role<who>), I want to (perform an action <what>) so that I can (achieve a specific goal<why>).
Below, I have discussed a few reasons why this format for user stories should be used:
- If the user story is written in the first person, the reader’s mind instantly starts visualizing what the user is. Once Paul McCartney was interviewed about why Beatles songs get immense popularity and fan following. His reply was because they use a lot of personal pronouns in their compositions. Due to the use of pronouns, people easily connect to their music/songs. A few examples of their exemplary songs include “Isn’t he a bit like you and me,” “I am he as you are, he as you are me and we are all together”, and “I Saw Her Standing There”.
- Adding a structure to your story helps the product owner understand what the feature is, who benefits from it, and what the value of it is. This, in turn, helps them prioritize product features.
Below is a template for capturing user stories and customer requirements quickly and conveniently:
You can explore this template here.
You must keep on adding user stories by getting feedback from customers and prioritize them according to business value. This will help you in responding quickly to user requirements and reduce the headache of maintaining extensive documents. Different templates are required to arrange your user stories, as new user stories get added to your product backlog.
Taking an example from one of our clients in the aviation sector, a user story generally looks like this:
As a passenger, I want to search the available flights from California to New York for a given date so that I can select a flight with an affordable fare and minimal travel time (User story modified).
Estimate – 8 story points
Priority – High
Another example:
As a passenger, I want to do a free web check-in using a laptop so that my seat is reserved.
(But not all seats might be free, and there will be charges which the potential flyer needs to pay to book a seat online).
Or
As a passenger, I want to keep track of flight status so that I don’t miss it (but there may be incidents of flight delay due to bad weather or technical glitches, so the question is, will the booking app take care of such mishaps. The app may not accurately report such a situation of a flight delay, and it might get hung due to an overload of irritated customers logging into it.
So the question is – How can you add detail to your user story?
You can add detail to user stories in two ways:
- By dividing a user story into several small user stories so that each chunk is self-explanatory
- By including the acceptance criteria which clearly defines the <How> of the user story
Slicing User Stories – Why Should You Do It?
Software development being a highly unpredictable process, few items on the product backlog consume more time and effort compared to the remaining items. Hence for larger items, you might not be able to effectively estimate the timeframe and this can lead to a failure to complete the user story within a sprint. So if the scrum teams undergo a ‘refinement’ process by breaking down large product backlog items(PBIs), it ensures effective sprint planning estimates and a successful sprint completion.
Splitting or slicing user stories is a crucial aspect of refining the product backlog. You must appropriately size the user story so that it is neither too large nor too small and can be completed in a single sprint. It should be sized effectively and should be broken down into individual sub-tasks. Now coming to why you should it, so below I have listed a few key benefits:
- Learn faster
- Deliver more often
- Happier stakeholders due to faster delivery of working software
- Getting more in-sync with cross-functional teams
- Ease of prioritization
- More business value delivered to customers
- Less risk (less time “underwater”)
- Gives a better sense of team velocity
- Ease of planning
How Are User Story and Epic Related?
An Epic is essentially a large user story that cannot be delivered in a single sprint and usually captures a large body of work. If you have multiple user stories in a project within a common focus area, then it’s recommended to create an epic for all the user stories. These stories can be written in different ways to cover a large number of functionalities.
Things to consider while writing user stories:
- Documenting user stories – User stories could be written by any of the project stakeholders (Product Owner/Business Analyst, Scrum Master and/or the development team). The user stories should be written in SMART(Specific Measurable Actionable Relevant Time-bound) format.
- Use simple tools – Usually, writing user stories on index cards is an inclusive modeling methodology. Index cards ensure all major aspects of a story are covered and helps in achieving consistency.
A User Story has three primary components, in short, called the 3C’s:
Card – This is an invitation to initiate conversation, should address the “who”, “what” and “why” of the story.
Conversation – It refers to the collaborative conversation encouraged by the Product Owner involving respective stakeholders and team members.
Confirmation – The PO needs to confirm that the user story is complete (Acceptance Criteria), before it can be considered as done.
- Indicate the approximate size – We can assign story point estimates to an index card which can help in estimating the time duration for implementing a user story. We can use agile story point estimation methods, like planning poker or t-shirt sizing. The user story that needs to be estimated must be explained by the Product Owner and the development team will be asking questions in case they need any clarifications. If a user story’s point is more than 13 points it has to be broken down into smaller chunks. Planning poker estimates follow a Fibonacci series pattern (1,3,5, 8, 13, 20).T-shirt sizing estimates typically represent relative effort for a user story as (XS, S, M, L, XL, XXL).
- Setting priority – You can keep a stack of prioritized requirements by rearranging the cards. These cards have a priority indication scale with 1 being for top priority and 10 being for least priority. Prioritization can also be set in terms of high, medium and low. Choose the strategy that works best with your team and try keeping it simple.
- Focus on non-functional requirements – You can use user stories for defining the Non-Functional Requirements (NFRs) as well. For example, students purchasing bus tickets online is a user requirement whereas system response time and compatibility with web browsers are NFRs.
User Stories In Agile Lifecycle
Product Backlog, Sprint Backlog, and Sprint Refined Backlog – Product owner sets the priority in the product backlog. The team (usually BA ) picks the user stories from the product backlog and puts it in the Sprint Refined backlog. Development team picks user stories from refined backlog and commits them for a Sprint.
In Agile methodology, each sprint backlog comprises of different user stories. A user story’s lifecycle is crucial in terms of checking progress during development, calculating team velocity, and quality of delivery.
Conclusion:
Contrary to the waterfall methodology, in Agile the user story lifecycle offers better visibility of the team’s progress. In the waterfall methodology the quality assurance, as well as user acceptance takes a lot of time as the software delivery is delayed until the fag-end of the project. While in agile, the customer feedback can be received early on in the project life-cycle minimizing overall project risk. Delivery cycles are more defined and visible to the product owner and the development team which enhances the team’s overall productivity and provides customer satisfaction.
For questions regarding user stories for improved employee engagement, feel free to contact us at info@people10.com
Author
Co-founder of People10, a 'total agile' software development and consulting company.