The traditional way of looking at project/product requirements involves thinking about the complete customer needs and then detailing the whole at fine-grain levels by creating a scope document for the solution. This way of working is unsuitable when we want to discover the customer/ user requirements incrementally. User Stories helps us in exploring user needs incrementally. The user story is a lightweight way of talking about small slices of the User’s requirements for the Product.
Let us talk about the User in User Story first. Here I am taking a hypothetical product, and we are naming it wowhotelsdotcom ; the purpose of this website is to assist in finding the best value for money stay options. Based on the initial research, the website stakeholders have agreed to focus on the following user types. The user types are an example. Therefore, before exploring the User Stories for the Product, we should first identify the Users and clarify what they want to do with the Product.
Solo Traveller
Looking for low prices, they are ok to go too far locations if that helps save money, only looking for a few recreation facilities inside the hotel. Usually, they don’t take lunch and dinner at the hotel; they stay out of the room and come back in the evening with a packet of food and drinks. The usual stay duration is two days.
Group Traveller
Looking for low prices and space for group activities, they want a hotel near city attractions, looking for recreation facilities inside the hotel. Usually, they eat dinner at the hotel, so they enjoy good food options; The usual stay duration is one week.
Hotel Manager
The manager is responsible for the profitability of the hotel. Therefore, the manager is very interested in ensuring resource utilization.
High Level Solution Vision
We support travel for the best prices and flexibility to choose what’s right for them. We do it by making our website super straightforward and speedy.
After identifying the solution vision and target users, the next step is exploring the users’ needs. Various tools are used to discover user needs, like Customer Interviews, Expert Stakeholder Interviews, Observing day in the life, discovery surveys, observing discussion forums, and sales force feedback. Based on these team may create a list of requirements users have for the product. These requirements are not elaborated in one go but rather get elaborated progressively in agile ways. This List of requirements is called “Product Backlog”. Now here comes the tool User Story. The items in the product backlog can be managed using User Story.
A user story describes a requirement and functionality that will be valuable to either a user or purchaser of a system or software. User stories have three aspects a
Ron Jeffries has named these three aspects as Card, Conversation, and Confirmation.
The Card gives a concrete view of a user story, but it should not be equated with documentation; the Card contains the description of a user story, but the details are worked out in the Conversation and finally recorded for verification in the Confirmation.
As an example of a user story see Story Card 1.1, a story card from the wowhotelsdotcom.
User Story Card
We generally write the user story with the following structure:
As a < user/user role / user type/user persona >
I want to <do an activity/action with system>
So that < I get my need met. >
Some of the other sample Stories might be
1.2: As a Solo Traveller, I want to know the best available prices for the whole month for the selected hotel to choose check-in and check-out dates accordingly.
1.3: As a Solo Traveller, I want to know nearby hotels rate so that I can find the best value for money for myself.
1.4: As a Solo Traveller, I want to know the hotel’s food menu so that I can consider it while selecting the hotel.
1.5: As a Solo Female Traveller, I want to know the amenities available in the room so that I can consider them while selecting the hotel.
1.6: As a Group Traveller, I want to know the distance between the hotel and public transport points to consider while selecting the hotel.
1.7: As a Group Traveller, I want to know the price option of room and meals to consider while selecting the hotel.
Where are the details?
When the development team reads card 1.1, are they getting the necessary details to create the functionality? For example, do the development team know which details to share to satisfy the solo traveller’s need to find the right hotel? The details will emerge as a result of the Conversation. Conversations between the development team, product owner and stakeholders happen as a part of backlog refinement activity. While doing backlog refinement
Card 1.1
As a Solo Traveller, I want to find hotel details so I can select the right hotel for me.
It looks too big for development in one sprint/ iteration. To detail this user story, they collaborated with the product owner and spitted in following user stories.
Card 1.1.1
As a Solo Traveller, I want to find details of recreation facilities so I can select the right hotel for me.
Card 1.1.2
As a Solo Traveller, I want to find details of nearby areas so that I can select the right hotel for me.
Card 1.1.3
As a Solo Traveller, I want to see photographs of facilities so that I can select the right hotel for me.
Card 1.1.4
As a Solo Traveller, I want to read reviews posted so that I can select the right hotel for me.
All small stories should be as independent as possible to give a small slice of value to the user.
Let us get into the Conversation with the Product Owner for the story card
Card 1.1.1
As a Solo Traveller, I want to find details of recreation facilities so I can select the right hotel for me.
Dev Team: What recreation facilities would you like to know about?
Product Owner: I have seen travellers interested in Swimming pools, fitness centres and restaurants.
Dev Team: What is needed in the swimming pool info?
Product Owner: Just Yes Or No is good enough
Dev Team: What about other facilities?
Product Owner: Just Yes / No for all.
Dev Team: anything else?
Product Owner: Make sure it looks nice on the page since its plays a critical role in making a booking decision.
Recording the Confirmation Tests
Once the Conversation gets over, the dev team and product owner collaborate to summarize the verification test points. Here are possible Confirmations.
Verify that the swimming pool details are displayed in Yes / No format
Verify that the Fitness centre details are displayed in Yes/No format
Verify that the restaurant details are displayed in Yes/No format
Verify that the look at feel remain consistent with the current page
Verify that information is presented in a tabular format to see it at once.
The 6 Attributes Of Effective User Stories – INVEST
Bill Wake came up with the INVEST acronym to give characteristics of good user stories: Independent, Negotiable, Valuable, Estimable , Small, and Testable.
Independent: When stories are linked with other stories, they create planning and estimation challenges. For example, suppose the customer has selected a high-priority story dependent on a low-priority story; dependencies make estimation a problematic job. Therefore, as much as possible, we should avoid introducing dependencies between stories.
Negotiable: Stories are brief, and the details are explored in conversation progressively. Stories are not written requirements; rather, they are tools to discover requirements collaboratively and progressively. This means at any time development team, and product owner can renegotiate the story, all in acceptable till both parties agree to it.
Valuable: Since Stories are explored from the user’s view, a story should provide value to the user. Value can be a benefit, risk mitigation or knowledge gain, or anything the user sees value in.
Estimatable: Development team should be able to estimate the user story; one of the primary reasons is to ensure that story is small enough to fit in a given sprint/iteration
Small: One of the purposes of User Story is to support small batch size development. If one requirement takes a long time to develop, the feedback on the implementation also gets delayed. In agile ways of working, we want to get to working software fast, so we reduce risks. So stories need to be made small enough to fit in one Sprint/Iteration of the development team.
Testable: Stories should be testable to help determine its details and completeness. A story should have acceptance criteria / Confirmation Criteria added as we detail it. The more objective is acceptance criteria, the easy to communicate the details and verify the completeness.
To Conclude :
User Storie helps us discover and validate requirements collaboratively and incrementally. The Card, Conversation and Confirmation help in adding details Just In time. User Stories should not be understood as another way of documenting the requirements; rather, they should be understood as a way of delivering value incrementally.
Feel free to add your comments and questions on User Story in the comment area. In addition, you can join our Certified Scrum Product Owner training sessions to learn other aspects of Agile Product Management.
