Written by Agile ways of working promote short cycles of value delivery. The short cycle ensures that the team delivers something quickly, and it also helps correct the assumptions/errors early in the development cycle. To enable short feedback/delivery cycles, we also need to discover an approach that helps us in finding requirements in small chunks. User stories play a critical role in enabling that. User Stories shifts the focus from writing large requirement documents to discussing small requirements.
In the User Story approach of requirement exploration, the focus is not on writing but on developing a shared understanding of the requirement. It is achieved by start writing few lines (Card), followed by discussion (Conversation), and finally recording the results of the conversation in the form of acceptance criteria (Conformation). This approach is many times also called Card, Conversation, and Confirmation.
So we can say the User Stories get started with few lines to record small user requirements, and a short template can help us in capturing this well.
As a < user >, I want < some goal > so that < some reason >.
User, this is the first starting point; the team should have a common understanding of what type of users matter to the given product, type of User can be expressed as user personas or user roles or just as user category. Based on the product vision, the team should develop the list of user persons/roles before thinking about user stories since we need to know the person before knowing the person’s requirement.
Once we know the User, we want to understand what this User may want to do with this application and why. Therefore, the remaining two sections of the User Story template focuses on the what and why part.
If the team is working on a hotel booking product, they need first to discover the user personas/type of users they might want to focus on. Say they may create a kind of users as Budget Vacationer Traveler, Business traveler, Family Vacationer, and frequent business traveler. Depending on the product focus, they may also define users as Solo male travelers, solo female travelers, couple travelers, and group travelers. You may see the requirement exploration is impacted a lot by defining the User itself, so before talking about User stories, it is usually a good idea to talk about the User first.
Let us hypothetically focus on one User to create an example for User Story.
User: “Solo Male Traveler”
Requirement: Know about recreation facilities are available in the hotel
Reason: My decision to book a hotel is influenced by recreation facilities since I do not want to sit and watch TV.
Once the first level of information is recorded, the team will discuss this requirement at the right time. Finally, the development team will ask the product owner about this user story; here are some examples.
Team’s Question: Should we show recreation options of the hotel, or should we also show things which are available nearby, say in a radius of one kilometer.
PO Answers: We better focus on facilities available in the hotel.
Team’s Question: Should we show all Free and Paid recreation options?
PO Answers: Yes, show both, identify free by some way, for paid one person can get into details to see pricing.
Team’s Questions: What is all information we should show about the recreation facility?
PO Answers: Quick description and photographs of people using it.
So after step 2, now we are clear about the discussion part; now it’s time to record the acceptance criteria for confirming the requirements.
User Story :
As a Solo Male Traveler, I want to know about the recreation facilities available in the hotel to choose the right hotel for myself.
Acceptance Criteria:
Verify that the User can see recreation facilities attached with hotel
Verify that the User can get descriptions and photographs of the recreation facility
Verify that the User can identify the complementary and paid facilities while seeing the details
Verify that the User can find the price attached with paid facilities
So, after going through Card, Conversation, and Confirmation, the user story may look good to get started for development, so confirmation details may evolve while the team is doing implementation also.
We need to keep in mind that User Story should be small enough to be fully implemented in one iteration/ sprint. If it is not, the team should split it into smaller stories.
You may want to check out some of the examples of User Stories here.