5 Common User Story Writing Mistakes
Summary
TLDRThis video script outlines five common mistakes teams make while writing user stories and offers solutions to avoid them. It emphasizes the importance of avoiding excessive detail, steering clear of technical jargon, correctly identifying the 'why' to convey business value, using 'not' judiciously, and avoiding conjunctions that can complicate the story. By addressing these pitfalls, teams can enhance their development process and deliver better user experiences.
Takeaways
- π Avoid adding too much detail in user stories to prevent stifling creativity and flexibility during development.
- π Postpone decisions on details that could constrain other solutions to keep the user story open for discussion.
- π« Refrain from writing technical stories that may confuse stakeholders and instead focus on end-user value.
- π Utilize the 'five whys' technique to convert technical requirements into user stories that convey business value.
- π€ Clarify the business value in the 'so that' section of a user story to ensure it aligns with the end user's needs, not just business requirements.
- π« Avoid using the word 'not' in user stories as it can lead to ambiguity and a lack of specificity in requirements.
- β Reframe user stories without 'not' to make them more specific and verifiable, facilitating clear development goals.
- π« Do not use conjunctions within a user story, as they often indicate that the story can be split into multiple, more focused stories.
- π Use acceptance criteria wisely to highlight logical points without overcomplicating the user story.
- π Writing user stories correctly is crucial for productive development and can significantly impact the project's success in the long run.
- π Encouragement for viewers to engage with the content by liking, subscribing, and providing feedback in the comments.
Q & A
What are the common pitfalls in writing user stories according to the video?
-The video outlines five common mistakes: adding too much detail, writing technical stories, writing the incorrect 'why', using the word 'not' within a user story, and using conjunctions within a user story.
Why can adding too much detail in a user story be problematic?
-Adding too much detail can make it hard to change or come up with new ideas during development, and it can shut down conversations by implying that all questions have been answered.
How can we avoid adding too much detail in user stories?
-By postponing decisions on details that constrain other solutions and writing user stories with as little detail as necessary to capture the intended product value.
What is a technical story and why is it problematic?
-A technical story contains only design or technical requirements and is problematic because it may not convey the business value to the product owner and stakeholders, making it hard for them to assess its importance.
How can a technical story be converted into a user story?
-Using the five whys technique to uncover the underlying business value and reframe the story from the perspective of the end-user.
What is the purpose of the 'so that' section in a user story?
-The 'so that' section states the business value of the user story to the end user, explaining why the feature is beneficial to them.
Why should the word 'not' be avoided in user stories?
-Using 'not' can make the story less specific and harder to verify, as it implies a condition that can never be fully met.
How can the use of conjunctions in a user story be problematic?
-Conjunctions often indicate that a single user story can be broken down into multiple stories, which can lead to confusion and a lack of focus.
What is an example of a user story that has too many specific details?
-The example given is an online bank customer wanting to sign into their account with detailed acceptance criteria like denying access after five failed attempts, providing a password retrieval option, assisting in creating strong passwords, and providing an option to change login details.
What is the improved version of the user story about a customer ordering food and locating previous orders?
-The improved story is: 'As a customer ordering food, I want to locate previous orders so that I can select a different item to eat this time.'
Why is it important to write user stories correctly?
-Writing user stories correctly is important because incorrect user stories can sabotage productive development, and taking the time to write them well will pay off in the long run.
What feedback does the video encourage viewers to provide?
-The video encourages viewers to provide valuable feedback in the comments section after watching.
Outlines
π Common Pitfalls in Writing User Stories
This paragraph discusses the importance of writing effective user stories and identifies five common mistakes made by teams. The first mistake is adding too much detail, which can hinder flexibility and innovation during development. An example is provided to illustrate how acceptance criteria can become overly specific and limit discussion. The second mistake is writing technical stories that focus on design or technical requirements rather than end-user needs. The 'five whys' technique is suggested to convert these into meaningful user stories that convey business value. The paragraph emphasizes the need for simplicity and clarity in user stories to avoid misunderstandings and to foster productive collaboration between developers and stakeholders.
π οΈ Improving User Story Quality for Better Development
The second paragraph emphasizes the long-term benefits of taking the time to write user stories correctly. It highlights the consequences of incorrectly written user stories on development productivity and encourages viewers to appreciate the value of well-crafted user stories. The speaker invites viewers to engage with the content by liking the video, subscribing, and providing feedback in the comments. The paragraph concludes with an anticipation of the next video, creating a sense of continuity and engagement with the audience.
Mindmap
Keywords
π‘User Story
π‘Common Pitfalls
π‘Technical Stories
π‘Five Whys Technique
π‘Business Value
π‘Acceptance Criteria
π‘Conjunctions
π‘Mistake
π‘Product Owner
π‘Stakeholders
π‘Development
Highlights
The importance of avoiding too much detail in user stories to allow for flexibility and creativity during development.
An example of a user story with too many specific details that could limit discussions and stifle innovation.
The issue with writing technical stories that lack a clear business value from the end-user's perspective.
Using the 'five whys' technique to convert a technical story into one that makes sense from a business perspective.
The correct approach to writing user stories that focus on the end-user's needs and the business value they provide.
The common mistake of confusing the 'so that' section of a user story with business requirements instead of business value.
An example of an improved user story that clearly states the business value to the end user.
The pitfalls of using the word 'not' in user stories, which can lead to ambiguity and difficulty in verification.
A suggestion for rephrasing user stories to be more specific and verifiable without using the word 'not'.
The exception to using 'not' in acceptance criteria for making logical points.
The problem with using conjunctions in user stories, which often indicates that the story can be broken down further.
An example of splitting a complex user story into two separate, more focused stories to improve clarity and manageability.
The long-term benefits of taking the time to write user stories correctly for productive development.
Encouraging viewers to give feedback and engage with the content for continuous improvement.
The call to action for viewers to subscribe and like the video for more content on user story writing.
A summary of the five common mistakes made while writing user stories and how to avoid them for better development outcomes.
Transcripts
All right.
So obviously there's a lot more that goes into writing a good user story, like
understanding the business domain, needs of the end user and expert knowledge.
But because one of my goals on this channel is to help you develop an
awareness of the common pitfalls and impediments, in this video, I will give
you five such common mistakes that most teams make while writing user stories.
Let's go for it.
Mistake number one, adding too much detail.
Too much detail in a user story can make it hard to change or come up
with new ideas during development.
We can avoid this by postponing the decisions on details that
constrain other solution.
Let's have a look at an example.
As an online bank customer, I want to be able to sign into my account so
that I can check my account activity.
So far
so good, but here's the acceptance criteria.
Number one, deny access to more than five failed attempts.
Number two, provide an option to retrieve password.
Number three, assist in creating strong passwords.
Number four, provide an option to change login details.
This story now has too many specific details and is capable
of shutting down conversations.
For example, the developer to whom this story will be assigned may think that all
of the questions around this particular feature have already been answered.
There is no more space for discussion with the business and therefore the delivery
is only a matter of checking the boxes.
So it would be best to write a user story in as little details as possible
to capture the value that the product intends to deliver adequately.
Mistake number two, writing technical stories.
Now it often happens that teams write user stories that contain only
design or technical requirements.
For example, as a developer, I want to add a credit card field to the billing table.
This seems like a pretty easy thing to understand and execute
from a developer's perspective.
However,
the product owner and stakeholders may have trouble understanding what
the business value is and whether it's worth the risk of doing.
This is a technical story and not the one written for an end-user
who will interact with the system.
Fortunately though, we can easily convert any developer or
technical story into a user story
that makes perfect sense from a business perspective.
We can do this using the five whys technique.
Let's have a look at an example.
If the user story is as a developer, I want to add credit card field to
the billing table, asking the five whys on this particular technical user
story would look something like this.
Why are you adding the field to the table?
Let's say the response you get after the first why is, to store and
retrieve the payment information.
Why do you need to store entry of the payment information?
To expose the new field in the user's profile.
Why do we need to expose the new field in the user's profile?
To present the payment option on the webpage.
Why do we want to present the payment option on the webpage?
So end users have multiple options for payment.
Why do we want the end users to have multiple options for payment?
So they can buy our services on credit if required.
And that's our final user story.
As a customer, I want to pay using credit card so I can buy
the services I like on credit.
All right, let's move on.
Mistake number three, writing the incorrect why.
The so that section of the user story states the user story's
business value to the end user.
Most people confuse it with the business requirement.
For example, as a customer ordering food, I want to locate previous orders to see
how many orders I have placed to date.
The problem with this user story is that it doesn't explain the business value.
I mean, why a hungry customer would want to see how many orders are placed to date?
Number of orders placed to date is another feature slash business
requirement and not a business value that this particular user story provides.
And improved user story would be as a customer ordering food
I want to locate previous orders
so that I can select a different item to eat this time.
Mistake number four, using the word not within a user story.
Not implies in no situation or no amount of time will be
sufficient to ensure compliance.
For example, in the user story, as a returning user, I do not want to enter my
password every time I access my account.
Now there can be a hundred ways to fulfill this condition, but if you rewrite
the story without the word "not", It will be more specific and verifiable.
The improved user story could be as a returning user I want the
password to be automatically filled in so that I can access my account
without reentering my password.
There is however, an exception to this rule.
You can use the word, not in acceptance criteria to make a logical point.
For example, the login form should not be in blue font.
Mistake number five, using conjunctions within a user story.
Conjunctions are such words and phrases that combine the basic
sentences into complicated ones.
Examples of conjunctions are and, or, but, and as well as the use of
conjunctions in a user story is usually a sign that you can break the story
into several different user stories.
For example, a story as a UI designer, I want to create and view
an issue so that I know what to test.
This user story can be easily divided into two separate users.
As a UI designer, I want to create an issue so that I know what to test.
And as a UI designer, I want to view an issue so that I know what I am testing.
User stories written incorrectly can sabotage productive development,
therefore taking the time and effort to write them correctly will
definitely pay off in the longer run.
So there you have it.
If you liked the video, then give it a thumbs up subscribe,
and don't forget to provide you valuable feedback in the comments.
I'll see you in the next video.
5.0 / 5 (0 votes)