5 Common User Story Writing Mistakes

Summary

This 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

00:00

📝 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.

05:04

🛠️ 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.

Keywords

💡User Story

A user story is a simple description of a feature told from the perspective of an end user. It is a fundamental concept in Agile software development, used to capture a requirement in a way that the customer can understand. In the video, the theme revolves around the common mistakes made while writing user stories, emphasizing the importance of capturing the value intended to be delivered by the product.

💡Common Pitfalls

Common pitfalls refer to the typical errors or difficulties that teams encounter. The video aims to develop an awareness of these issues, specifically in the context of writing user stories. It provides insights into the mistakes that can hinder effective communication and development processes within a team.

💡Technical Stories

Technical stories are user stories that focus on the technical requirements or design aspects rather than the end-user's perspective. The video script warns against writing such stories, as they may not convey the business value to stakeholders and can lead to misunderstandings about the purpose of a feature.

💡Five Whys Technique

The 'Five Whys' is a method used to explore the cause of a problem or decision by repeatedly asking 'why' until the underlying reason is reached. In the script, it is suggested as a way to convert a technical story into one that makes sense from a business perspective by understanding the deeper reasons behind a technical requirement.

💡Business Value

Business value refers to the worth or utility that a product or feature provides to the business and its customers. The video emphasizes the importance of articulating this value in user stories, rather than focusing solely on the feature or requirement itself, to ensure that the development aligns with business goals.

💡Acceptance Criteria

Acceptance criteria are the conditions that a product must meet to be accepted by the customer or end-user. In the script, it is pointed out that having too many specific details in acceptance criteria can limit the scope for discussion and innovation during development.

💡Conjunctions

Conjunctions are words that connect clauses or sentences. The video advises against using them in user stories because they can lead to complex, combined stories that should ideally be broken down into simpler, more focused stories for clarity and manageability.

💡Mistake

The term 'mistake' is used throughout the video to highlight the errors made in the process of writing user stories. Each mistake is explained with its potential impact on the development process and how to avoid it, making it a central concept in understanding the video's message.

💡Product Owner

A product owner is the person responsible for managing the product backlog and ensuring that the team is working on the right items. The video script mentions the product owner in the context of understanding the business value of user stories and the importance of writing stories that are meaningful to them.

💡Stakeholders

Stakeholders are individuals or groups with an interest or concern in the project or product. The script discusses the importance of writing user stories that are understandable to stakeholders, so they can assess the value and prioritize work accordingly.

💡Development

Development in this context refers to the process of creating or improving a product or software. The video focuses on how the way user stories are written can either facilitate or hinder the development process, emphasizing the need for clear and concise communication.

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.