User stories are a standard tool in agile development, and they are one of the best ways to communicate with your team about what you want to accomplish. A User Story is a short description of a feature or enhancement that fits into the overall context of your product.
A good user story should answer three questions: who, what, and why? In other words, it should describe who will be using the feature (the user), what they will be doing when using it (the action), and why they're doing it (the motivation).
Story writing workshop is important to understand User Story in detail and who are the users of that particular functionality, and what the users do to use the product.
Top Challenges in Writing a User Story
Getting Teams Engaged
To get teams engaged with building a well-formed user story, it's essential to ensure everyone is on the same page about what "well-formed" means. Getting teams on the same page will help to avoid confusion and miscommunication, which are significant contributors to the challenges you are trying to solve.
Developers need to understand that writing user stories around business value is a way of describing what problems your product or feature solves. If you are unclear about what problem your solution resolves, then it's unlikely that anyone will be able to build something useful—including developers.
The best way to avoid this situation is by using tools that allow your team to collaborate quickly and effectively. One option is using a project management system like Basecamp, Jira, or Asana—all are great options because they're easy to use, offer features like file sharing and task assignment, and integrate seamlessly with other tools such as Slack or Trello. Another strategy is ensuring your team has access to online collaboration tools like Github or Gitlab so they can easily share code snippets.
Adding Too Much or Too Little Detail
One challenge of building a well-formed user story is adding too much or too little detail. The best way to avoid this is to ensure that your content is informational.
If you are writing from a software developer's point of view, ensure you don't include any unnecessary details about the story itself. It needs to provide enough information for the developers to be able to complete it, but it shouldn't include anything that could be considered excessive.
Informational content is vital when writing user stories because it lets software developers know how to complete a task or build a feature. In other words, if you include too much information in your story, developers will have too much on their plate and won't complete it correctly.
Another way is by using the INVEST method, which stands for:
I - Independent. The story should be independent of other stories to work.
N - Negotiable. The team can negotiate the scope of the story as needed.
V - Valuable. It should add value to the product and company.
E - Estimable. It should be estimated in terms of effort and time.
S - Small. It should be small enough to complete within one iteration (usually two weeks).
T - Testable: To make the story 'done,' it should complete the testing stage by completing all the possible combinations.
If you are new to writing software user stories, try using the simple template: "As a [persona], I want [goal] so that [reason]." You can add additional detail if needed, but try to stay moderate.
Splitting Stories
This problem arises because we want to be able to tell the story of what our product will do and how it will do it. However, when you try to write down every single step that your product will take, you end up with a lot of steps that aren't necessary.
For example, say you have a product where users can order food from their phones. You could write down all the steps:
The user opens the app.
The user enters their location.
The user selects a restaurant from a list of restaurants nearby (or types in a name).
The user selects an item from the menu (or types in the item number).
The user adds items to the cart and checks out by paying online with a credit card or PayPal account.
One way around this challenge is using epics rather than stories as your main unit of work. Epics are larger pieces of functionality that contain several related features. For example, an epic could be "add new user" with several subtasks like "create an account," "confirm the email address," "set profile photo," etc., which would then become individual stories within the epic once they were completed (or broken down further if necessary).
How to Write a Well-formed User Story?
Don't Solely Rely on User Stories
Designers and developers should rely on more than just user stories to plan and build software. They should also consider other factors, such as the project's business goals, the technical limitations of existing technologies, and the current architecture of existing systems. These additional factors can help you ensure that your project is successful in terms of time and money spent.
Keep Your Stories Visible and Accessible
When working with Agile software development, it is important to keep your user stories visible and accessible. It means that you should be able to see all of your user stories at any given time so that they can be used as a reference when working on development tasks. Many strategies can be employed to ensure that stories remain visible and accessible.
One strategy is to use a backlog board where all the stories are listed from highest priority to lowest priority. Another strategy is to use index cards containing each story's name so they are easily accessed at any time. A third strategy is to use software such as Asana or Jira, which allows users to create tasks that can then be assigned and tracked by other team members and management members.
Use (Paper) Cards
The first step in writing a well-formed user story is to choose the right card. Each card should be 3x5 inches and made of paper.
After choosing your card, you'll need to write your user story. When writing a user story, ensure it's as clear and concise as possible. It will help ensure everyone understands what needs to be done and why. The story's subject should always be singular; this makes it easier for readers to understand who is involved in the story.
Finally, once you have written down all of this information, take your card to the product owner, who will review it before approving it for development.
Add Acceptance Criteria
The next step in creating a well-formed user story is to add the acceptance criteria to the story. Acceptance criteria are conditions that must be met before an item can be considered complete, and they should be written from a software developer's point of view. Instead of discussing what a user will see or experience, it means that you should focus on what needs to happen behind the scenes for their experience to work as intended.
Refine the Stories Until they are Ready
A user story is not a specification. It is just a short description of what a user needs to do. Writing a user story as an acceptance test is unnecessary, but it may be useful to think about how you would like to test the feature you describe.
It is useful to write user stories from the user's point of view rather than the software developer's or business analyst's. For example, if you are describing an online shopping experience, then it might be more appropriate to use words such as "see" and "click" rather than "search" and "order."
Start with Epics
You should write an epic for each feature you want to include in your application. An epic narrative tells how your app will help people accomplish their goals. It is like a mission statement but has more details and explains how customers will use your app.
Next, you can break down each epic into user stories. User stories are short sentences (often one sentence) that describe how users interact with your app to achieve their goals. They should be written from the customer's point of view, not from the developer's or designer's perspective.
Finally, each user story should have acceptance criteria: clear specifications for what it means for a user story to be complete and accepted by stakeholders.
Set a Single Objective for the Meeting
Objective should be MVP (Minimum Viable Product.) and engage the team in various discussions on top user Stories with the Product Owner.
Have the Right Participants
Scrum master, Product Owner and other stakeholders, Development team (Agile coach) (optional) may be User Roles.
Ask the Product Owner About the Top Requirements/Features to be Delivered
In MVP, Brainstorm the requirements in detail, which will help in a more innovative solution. Visualize the relationship between stories.
User Story Mapping Technique
Document each step in the process. Writing the sequence of steps needed to complete the user story will make it clearer, which may have been overlooked and easier to estimate. The chances of missing any functionality can be minimized.
We can read the below functionality login and enter credentials, you may also click on “forgot password” and then submit.
Another advantage of using mapping is that we can get the prioritized list of user stories as mentioned in the below diagram by lanes.
SPIDR has come to our rescue. Beautiful concept was given by Mike Cohn.How to Split a User Story?
Spikes
The user story is large and difficult to split when there is a spike in activity involved in it. Spike doesn’t lead to any working functionality but is just for the knowledge enhancement for the team for example-Investigation of new technologies and investigating different tools etc.
Paths
The user story may be large because of the different paths associated with it. See the flowchart below to understand the example: In an e-commerce website, after selecting the items in the payment method cart, the payment method can be visa card, MasterCard, or PayPal.
So, it is recommended to split the user story based on the number of paths taken.
It can be easily logically split into small stories as:- As a <user>I want to pay using credit card or
- As a <user>I want to pay using PayPal
Here, there is no need to split using a visa card or mastercard, as both come under the category of credit cards.
Interfaces
Split a story across multiple interfaces (mobile OS or browser) or data interfaces.
Example: As a <user >I want to display on an Android device.
As a <user > I want to display on an IOS device.
As a <user > I want to display in a web browser.
So, it can be split into 3 different logical user stories.
The same is the case with the browser also. Split by different browsers example: Chrome, IE, Mozilla, etc, because working in all browsers will take time and the efforts would be great.
There are a few scenarios in which there are complex interfaces. A perfect example will be a sign-up form (with the details) but a blank UI. It means the functionality is fully working with buttons and links but no color and proper UI/UX image. The UI can be built in subsequent sprints with a different user story. So, separating the UI work from functionality is also a good way to split the user story.
There is a similar case when the user story says- As a <user> import data from a file and the note says (Must support: CSV, Excel and XML) Split each supported file format with a different user story as:
As a <user> I want to import data from a CSV
As a <user> I want to import data from Excel
As a <user> I want to import data from an XML
Data
Develop an initial story with a subset of data.
Example: Suppose I need to buy a car.
As a car buyer, I want to know what is the best car in the market.
To come up with this decision, we need to investigate many things example considering mileage, cost, big, small, comfort, features, etc., as a separate user story.
As a car buyer, I want to buy a car with minimum cost.
As a car buyer, I want to buy a car with good mileage.
So, functionality is developed incrementally with different data inputs to buy a car.
Rules
Relax business rules or technology standards in an initial version of a story.
Sometimes a user story is considered as large because of the different business rules or business standards.
Example: I want to buy something online for my kid’s birthday party, at least 15 items. But the website shows there is a limitation of 2 items per buyer.
Relaxing a rule is sometimes followed by a user story which is a great way to split.
For example, in a project, we develop some functionality (sort the employees with their skill set). This will be a database query and may take quite a few seconds, depending on the load. So, there is a performance issue that is very important to consider. Better to split this as a separate user story.
But how to find out if the details are in the correct proportion or not?
The answer is “Retrospective.” Ask each team member if the detail that was given was enough to complete the user story in one iteration.
Just Enough and Just in Time
The reason is that if the information provided by the BA is not sufficient to complete the user story in one iteration, then there will a delay in the project delivery, and the customer will not be happy. Similarly, if the detail is too much, then a lot of work in upfront needs to be done, and the project delivery will be on time and with the exact functionality which was decided before the start of the sprint more like a waterfall model
- A very important aspect while defining user stories is user roles. Avoid writing user stories from the perspective of a single user, identify different user roles who will interact with the software. Write stories for a single user.
- Create constraint cards or write tests to ensure the constraints are not violated.
- Keep the user interface out of the stories for as long as possible.
Let us see some examples of user stories that look fine but can be written in a much more effective way.
1) As a Product Owner, I want to display my ratings on my webpage
Issue/Drawbacks- It is not only about “you.” Focus on End users and stakeholders.
Correct: As a trainer, I want to display my ratings on my web page so that the visitor can choose wisely.
2) Design Brochure Layout
Drawbacks: Not independent, No business value.
Correct: As a restaurant owner, I want to design Brochure Layout so that the visitor gets the order from it.
“Identification of Who, What and Why are the Key Factors”
So, the user story suggested format/template is:
As a <>, I want <> so that <Business value>.
Story Examples
Story | Description |
|---|
The user can run the system on windows xp and Linux | Good user story, but it still suggested to split into three (Windows,XP and Linux) |
The user can undo up to 50 commands | Good user story |
All graphing and charting are done by third party library. | Not a good user story as user will not care how graphing and charting are done. |
The system will use log4j to log all the messages | Not a good user story, and log4j should not be written as logging mechanism. |
The user can export data to XML | Good user story |
A user can quickly master the system | Neither quickly and master should be defined. Needs to be changed |
Conclusion
Whether you want to become a Certified Scrum Master, Agile Product Owner, or Certified Scrum Developer, we offer different courses to help you achieve your goals. We are passionate about what we do and want to ensure that our students are satisfied with their learning experience.
Frequently Asked Questions (FAQs)
How do you write a perfect user story?
A perfect user story has three parts:
A brief description of what the user is trying to do.
The problem the user is experiencing and how you will solve it.
The desired outcome: what will happen after you have implemented this feature?
What are the 3 Cs of user stories?
Cards: A card is a single story written in user-friendly language that readers can easily understand.
Conversation: A conversation is a collaborative effort between the writer and reader to ensure that the user understands the story and that it is being told in the most effective way possible.
Confirmation: Confirmation means that the reader agrees with what you have written, which means that you know your work is accurate and well-written.
What is a well-written user story?
A well-written user story is a brief statement describing what a user needs to achieve a goal. It can be as simple as "I want to do A" or as detailed and thorough as "I want to be able to do B, which will need me to do C."
.jpg&w=3840&q=75)
.jpg&w=3840&q=75)
