6 Benefits of Good User Stories

6 Benefits of Good User Stories

In previous two articles, we discussed:

Becoming user centric with User Stories and

How to write good User Stories

In this article, lets understand the fundamental benefits of good User Stories. I challenge teams that I coach to strive to realize all of these User Story benefits.

While you read the article, I encourage you to think: how can you get maximum value from applying User Stories? It could be a competitive advantage for your team!!

Don't forget to take your User Story Benefits Assessment at the end of this article.

Benefits-of-Good-User-Stories

Without further ado, here are the

Good User Story Benefits: 

 

1. Highest Value Delivery:

This User Story Benefit is the mother of all benefits. Done well, User Stories help deliver the highest value by focusing on small and immediate customer needs.

Traditional product development teams may spend months on a single function such as analysis, design, implementation etc, carrying a significant amount of work in progress without delivering anything that is directly valuable to the customer immediately.

How could you take the old school requirements approach and turn it upside down?

Agile Teams break down user needs into small features or tasks that can be implemented and delivered from few hours to few days. The ProductOwner actively prioritizes these user stories in terms of user value, risk, and business value to significantly increase the value delivered by a team within first few sprints.

Delivery of highest value early in the product development allows the Product Owner to:

a) Start earning returns early.

b) Reduces the amount of investment that the organization needs put in - as the return from the product starts to pay for the new feature development at some point during the development.

c) Significantly increase the ROI.

 

2. Fosters Collaboration:

Good User Stories due to their minimalist characteristic, inherently give way to collaboration among the product development team, the Product Owner and the users of the product. While the traditional teams depend heavily on detailed documents and electronic tools, most Agile Teams collaborate with users to plan, implement and deliver customer value.

Minimal writing of the user's needs encourage the team members to talk to the user(s) or the Product Owner when they are ready to implement a UserStory. These discussions allow room for diverse business-technical perspectives to come to light and gives way for creative and innovative ways of solving customer's needs.

 

3. Brings User Closer:

By focusing on delivering highest customer value with each user story, the Agile teams are compelled to regularly connect with and collaborate with end users. Minimally written detail also encourages for the team members to talk to the user.

The team members directly connect with the user to understand the user's perspective, challenges, pain points and opportunities that need to be addressed. The team members also get early feedback from users by demonstrating implemented User Stories as soon stories are DONE.

In case if you haven't read yet, check out my article - Becoming User Centric with User Stories

 

4. Building Blocks of the Product:

With each customer value delivering User Story, the product is built incrementally. Building the product incrementally allows to rapidly adjust it to a new direction. When sliced in smaller ideas to experiment, user stories allow for quick implementation and user feedback.

With each successfully implemented feature, the product gets shaped and the value of the product keeps increasing.

User Stories allow for easy addition and removal of features from the Product.

If the Product Owner decides to remove a non-performing feature from the product, it becomes easy to immediately toggle off a feature that was built as a small user story.

During development, when a user story acceptance criteria do not pass, the Product Owner can exclude that one story and still release rest of the features to production.

 

5. Boost Transparency:

Written collaboratively on index cards, User Stories increase transparency among with the team member, Product Owner, and stakeholders. The index cards remain visible to everyone and allow for better collaboration and faster decision making.

Improved transparency also increases the Trust within the environment.

Order of User Stories creates transparency about,

a) the priorities set by the Product Owner and

b) the customer segment / persona that is being addressed through a particular user story.

If any story has dependencies and is stuck, the impediment becomes immediately visible to all.

Transparency reduces a lot of waste from the process and improves team's effectiveness.

It is not uncommon for teams transitioning from traditional software development practices to Scrum, to write user stories as long documents.

Prompting these teams to store (freeze) these long written stories in electronic document repository or a tool. Most of the tools are not designed to radiate information or improve transparency. Severely reducing the transparency of User Stories and related information.

Any practice that hampers the transparency effectively slows down a team and increases churn.

The most effective tools - Index Cards and Sharpies are not meant for writing long documents.

Improved Transparency is a serious advantage teams can get from user stories. Higher transparency could be a game changer for teams new to Scrum.

 

6. Shared Understanding:

How can better User Stories create shared understanding? Unlike the traditional approach where the business team writes requirements and hands over the documents to the development team to implement, the Agile approach is for the Product Owner and the Development team members to collaborate and collectively develop, refine, and split the user stories.

Working collaboratively improves the shared understanding of:

a) what is expected by (need of) the user and what is feasible from technology and business perspective.

b) what is intended by the Product Owner and what is understood / implemented by the development team.

7. Reduced Risk:

Bonus benefit number 7. There is one more important User Story benefit that is Reduced Risk.

Most traditional teams are not equipped with and lack proactive measures of reducing risk.

Effective User Stories by creating transparency, improving collaboration, creating shared understanding and orienting the teams to focus on customer needs, eliminates various potential risks such as - lack of communication risk, technical risk, financial risk, business risk, etc.

 

While getting all these user story benefits would be sexy, many teams have asked me questions such as:

> Are these user story benefits achievable?

> Do other teams get these benefits?

> Does any team fully realize all these benefits?

> What are usual challenges that prevent teams from getting all these benefits?

To help you explore your own answers, I've created User Story Benefits Assessment. In about a minute, you can self-assess and get instant scores.

 

Take the User Story Benefits Assessment now! Just scroll to the end of this page to take the assessment.

 

I just want to say, many times the appreciation of these User Story benefits come only when any risks arise from not having these benefits.

 

Actionable Tip: Let me invite you to identify and share in comments below - potentials risks for your product and team if these benefits of good user stories are missing.

 

Evaluate the User Story Benefits You Get Today!!

Evaluate and get your score now!!

Disadvantages of User Stories

Yes, while the User Stories are good and beneficial to a team's agility, it also carries certain disadvantages.

Compliance Needs - Should you need a requirements document for compliance needs - User Stories will not suffice in most cases. Though I would highly recommend you first talk to your auditor or compliance team proactively before making a call on this.

Knowledge Transfer - Should a major shuffling happen within your team or suddenly 2-4 team members leave your team and new members join - User Stories will not help with the knowledge transfer. Well, neither do the detailed requirements do it fully. At least index cards won't be sufficient in this case to get started. Some team member or the Product Owner will need to take out time to get the new team members up to speed.

Interpretation - Minimal detail subject the User Stories to different interpretations. It may sometimes happen that the team members may miss having a detailed conversation on every aspect of the story. This may invite assumptions and interpretations which may cause errors.

 

 

6 ways the Scrum Master can improve Scrum Team Communication

If your Scrum Team's performance matters, it NEEDS to have excellent communication. In this article, First, I will show you why strong communication...
Read More

The Scrum Master as a Coach

Coaching is one of the essential skills required for a Scrum Master to be effective. Coaching along with Facilitation and Teaching skills enable the...
Read More

The Scrum Master as a Servant-Leader

Scrum Masters - Servant Leadership is one aspect that can set an effective Scrum Master apart from the pack. Are you looking to be an effective...
Read More

How to grow your leadership impact?

Improving your leadership impact is a holistic journey. There is neither a definitive step by step approach to it nor a single checklist of 7 ways...
Read More

How to Write Good User Stories? User Story Examples

write user story, writing user stories

Why care to write good User Stories?

Similar to what the developers say - the best code is no code, the best User Stories are not written, they are told.

Mastering the art of writing good user stories isn't easy. Writing User Stories with just enough information that entices further communication and promotes collaboration is difficult. Most people tend to write more, considering useful User Stories to be mini versions of requirements documents.

Written well (read - written minimally), good User Stories become easy to understand and implement for the Scrum Team. Writing user stories that are small, and crafting user stories that are valuable, could in most cases solve one of the biggest challenges of the Scrum Teams - delivering shippable product increment every Sprint.

As discussed in my article becoming user-centric with User Stories - A User Story is a promise for further communication. Communication that should happen between the Development Team and the Customer or the Product Owner to create a shared understanding of the user's needs.

When crafted well, User Stories form the building blocks of a successful product envisioned by the Product Owner and desired by the customer.

In traditional product development environment, the Product Owner or Business Team would write detailed requirements they want to be implemented. The team would simply implement these requirements to the extent they understand it. Agile teams use User Stories and challenge this rationale.

User Stories require identifying who (a user) exactly will use the feature being asked to develop and specifying what benefit the user will get. This helps remove ambiguity and offers clarity in understanding the story (need) of a User.

A user story card may outline “why” - the benefit, “who” - the user and “what” - the feature or action.

The closest term for the User Story as used in Scrum is Product Backlog Item (PBI). PBI may refer to User Story, Feature, Technical Enhancement as well as change required in the feature.

What does Writing User Story mean for Scrum Roles?

In order to understand what makes a good User Story, it is important to understand what does the User story mean for everyone involved in writing+implementing user stories and their contribution.

Product Owner

For the Product Owner, User Stories are a way of putting user's needs, wish list items, hypothesis and everything else required of the product on a set of cards. The Product Owner collaborates with the development team to refine user stories. The PO orders these user story cards in order of the customer value, business priorities and risk for the development team to work on. User Stories also help the PO initiates the conversations with the Development team to create shared understanding about why, what needs to be implemented, who will benefit from it and how.

Development Team

User Stories open avenues for the Development team to get closer to the user's need, who will benefit from it and formulate how they would implement it to achieve the desired outcome. User stories also help with tracking the progress of the development within a sprint and create transparency within the Scrum Team. It helps plan the sprint.

Scrum Master

The Scrum Master ensures that the User Stories are transparent and that the team members and the Product Owner have a shared understanding of the User stories. If the Product Owner and the development team are bound by written contracts called requirements documents or the User Stories and are not collaborating, the ScrumMaster can facilitate communication and collaboration.

Scrum Master would take responsibility to help everyone understand the importance of keeping the user stories small, clear, concise, being flexible and allow for the most relevant user needs to emerge while discovery and development.

Most novice ScrumMasters end up doing just the opposite. They make sure the Scrum Team writes detailed user stories (kind of mini requirements documents), police around to ensure the electronic tool is filled with detailed descriptions, every possible acceptance criteria is listed and all 16 types of user story fields are filled.

User Stories encourages the Product Owner and the development team to collaborate with the user and to stay close to what the user needs. Scrum encourages collaboration by face-to-face communication. This makes using User Stories a logical fit (as a practice) with the Scrum framework.

 

Why do Teams Write Detailed User Stories?

I think the biggest reason for writing detailed user stories is - old habits.

However, many reasons compel teams to write detailed user stories such as:

  • Lack of Trust - Require sign-offs and approvals,
  • Traditional Mindset - Need proof,
  • Requirement Writing Experts, Business Analysts on the team,
  • Geographical distance between the PO and the Dev Team - Lack of transparency, need for approvals,
  • Regulated Environment - Healthcare, Banks, and Government domains require compliance with regulatory norms.
  • Client-Vendor Setup - Contracts, Need for approvals, CYA.
Writing User Stories

Detailed written requirements minimize the need for collaboration within the team and actively prevent the customer requirements to emerge during the development.

Writing detailed user stories is the 1st step to stifle collaboration within the Scrum Team.

A relevant question I recently asked on our LinkedIn Page about long & written documents is worth contemplating:

What if the #requirements documents writers 📃🖹,🖹 #status #report creators, #ppt creators and internal #diagrams creators were to seek feedback on the cost 💰of writing each page v/s its usefulness 📈??

Artifact Transparency allows regular inspection. The Scrum Master may help the team analyze if a one-page document will meet the need instead of writing a 10-page report.

The Scrum Master is responsible to identify smells that induce waste, and prevent agility and help the Scrum Team address the root cause of such dysfunctions.

User Stories Templates

The need for templates and standardization stems from simple and repetitive work.

In Complex domains, it is essential for teams to adapt practices based on the context. Standardization of any practice or artifact would actively resist adaptation.

The Product Owner of a Scrum Team I was coaching, recently asked me - What is the best User Story Template used by Scrum Teams?

Well, writing better user stories is not dependent on the user story template used. More important than finding the best User Story template, is, every team must establish a common language that everyone on the team understands. If the essentials are met, the user story template used doesn't matter much.

A simple User Story template, that originated from Connextra and widely used by product development practitioners involves these three elements:

As a <<USER>>,

I want <<FEATURE>>,

So that <<VALUE>>.

This simple User Story template narrates the value for the user. The primary focus of writing User Story using this template should be the Business value that the Product Owner is trying to achieve through the implementation of a particular User Story.

An adaptation of above user story template, that makes the focus on Business Value explicit, is below version:

To realize <<VALULE>,

as a <<USER>>,

I want <<FEATURE>>.

When to write a User Story?

What is the pre-User Story phase?

A pre-user story condition could be a:

  • Hypothesis,
  • Feature Idea,
  • Customer Need,
  • Business Opportunity,
  • Change in Markets,
  •         Experiment.

Any of the above may trigger the need for a new user story.

There is no specific condition required to write a new user story. Anyone including Scrum Team members and Stakeholders may write a User Story when they find a need and share it with the Product Owner.

How to Write User Story?

Here are three characteristics that help craft effective User Stories.

1. Identify the Business Value:

To make a product successful, the Product Owner tries to maximize the business value delivered. In order to maximize the business value, it is important to identify: a- the Business Value, and b- the effort required, associated with a user story.

Knowing the Business value helps the Product Owner order the User Story with the highest Business Value at the top of the Product Backlog.

Example: For a new e-commerce website to launch, the highest Business Value will be when a new user is able to buy an item from the website. Let's take a closer look. Traditionally, the line of thought for the sequential functionality being made available would have been in the below sequence:

1a. New user can register on the website

User Story Example 1:

As a First time visitor to the website,

   I want to be able to register on the website,

   So that I can browse and buy listed products from the website.

 

1b. Registered User can Browse items listed

Writing User Story Example 2:

   As a Registered Website User,

   I want to be able to browse listed products from the website,

   So that I can make my choice and buy a listed product from the website.

 

1c. Registered User can add items to the cart

User Story Example 3:

   As a Registered Website User,

   I want to be able to add items to the cart,

   So that I can buy a listed product from the website.

 

1d. Registered User can make payment for the items added to the cart.

User Story Example 4:

   As a Registered Website User,

   I want to be able to buy listed products,

   So that I can use the product I buy.

 

Looking closely at the User Stories above tells us that the website visitor would not be able to make a purchase on the e-commerce website till the time User Story 4 is implemented and made available at the website.

The Human brain thinks sequentially, and step-by-step. It is evident from the above User Stories that the Product Owner writing user stories is looking at the website from the perspective of the end user and trying to depict his/her sequential line of thought.

Now if you wear the hat of a Product Owner, you must think about how can the highest Business Value be delivered early?

That requires prioritizing user stories in a way that the highest Business Value User Story finds its place at the top of the Product Backlog.

If you thinking out of the box and not sequentially as the human brain is trained to think, here is an alternate option to craft the User Story:

Writing User Story Example 5:

   As a First-time visitor to the e-commerce website,

   I want to be able to buy a listed product,

   So that I can use the product I buy.

 

This means that the First-time visitor to the e-commerce website should be able to make the payment as a guest user without having to register - User Story Example 1.

Does "Buying a product" has more value than "Browsing products" - User Story Example 2?

Sure, any day!

Adding chosen products to the cart - User Story Example 3 is a nice to have and allows the user to buy multiple items at the same time. However, being able to buy the product - User Story Example 5 without registering, browsing or adding the products to the cart has the highest Business Value.

2. Identify the “Who”:

It’s important and imperative to identify the Customer being served before you think of writing a User Story. One of the most common mistakes done by novice Scrum Teams is to generalize the User segment being served by a User Story.

Identifying a narrow and specific User segment being served by the User Story, helps reduce the size of the User Story.

The User Story becomes specific and clear as to who - which customer, is being targeted. Many Scrum teams use User Personas for their product and specify a particular persona while writing a user story.

Example: I had once worked on a capability that was available to all Credit Card users on the desktop. Our team was developing the set of features to make the capability available on an App for Tablet (iPad) and Mobile users.

The team started with this User Story format:

   As an App user,

   I want <<FEATURE>>,

   So that <<VALUE>>.

Now we had an option to split the user story as a “Mobile App User” and “Tablet App User”. The Product Owner prioritized the “Mobile App User” over the “Tablet App User” since that User Segment had higher volume and more business value. So, the PO chose to go with:

   As a Mobile App user,

   I want <<FEATURE>>,

   So that <<VALUE>>

Then, we had an option to re-write the user story in to two User Stories - as an “Andriod Mobile App user” and “iOS Mobile App user”. The Product Owner prioritized the “iOS Mobile App user” over the “Android Mobile App user” since that was a User Segment with even more business value. So, we chose to go with:

   As an iOS Mobile App user,

   I want <<FEATURE>>,

   So that <<VALUE>>.

In addition to this, we had Silver, Gold and Platinum Credit Card, holders. The Product Owner prioritized the “Platinum Credit Card holder” since that was a User Segment with highest business value. Our user story looked like:

   As an iOS Mobile App user holding a Platinum Credit Card,

   I want <<FEATURE>>,

   So that <<VALUE>>.

This is the level where the Scrum team was clear as to who was served by implementing the User Story.

Identifying a very specific user segment provides clarity, flexibility, creates shared understanding, reduces risk and results in improved ROI for the efforts.

 

3. Understand the “What”:

Communicating clearly “what” will be delivered as a part of the User Story is crucial too. This is the part of the User Story where the customer has an avenue to communicate his/her perspective on what s/he needs – feature, enhancement, etc.

Example: In another implementation that I had a chance to work on, we were implementing the approval system of a large Custodian bank. Can you believe they were dealing with Billions of Dollars yet the process was pretty much manual?

Anyways, using this Business Process Management tool, various departments involved would review and approve the application from a Sub-custodian bank to become a registered Sub-custodian to the Custodian based in the United States. The end goal was to create an automated system where:

  1. The interested Sub-custodian would apply online with all the details and documentation required by the Custodian, once that is done
  2. The Custodian would do multiple levels of review within the departments that existed in the Custodian bank.
  3. The application would then be sent to the regulatory body for their approval.
  4. Once approved by the regulatory body, the Custodian Bank would revert to the Sub-custodian requesting additional documentation required to formalize and close the registration process with the Custodian Bank.

As it appears, this was a huge task by itself. The team decided to break it down into bite-sized features. Although the team was going to use an off the shelf product with most of the functionalities required, yet there was a lot of customization required at each step.

With the array of features required to be implemented, we chose to first target the internal audience with the Custodian bank and the various departments within the bank whose approval was required as part of the registration process. We narrowed down the User to one department within the whole approval flow. We then decided to drop off the option of being able to attach the documents to the approval flow. Now the User Stories looked like:

   As a Registration team member,

   I want to be able to review the Sub-custodian application,

   So that <<VALUE>>.

 

   As a Registration team member,

   I want to be able to approve the Sub-custodian application,

   So that <<VALUE>>.

 

   As a Registration team member,

   I want to be able to reject the Sub-custodian application,

   So that <<VALUE>>.

 

These were easier to understand and also gave the Scrum Team a perspective on what’s being sought. Each User Story was written (crafted) in a way that it could be implemented within a Sprint. Breaking it down to the specifics removed ambiguity. Keeping the User Story minimal encouraged the Development Team members to go talk to the customers or the Product Owner.

Summary:

Nailing the “who”, “what” and “why” of the User Stories, making them minimalistic, small, transparent, and valuable makes them viable survivable experiments for the Scrum team.

Minimally but well-written User Stories allow the Scrum Team to learn fast and inspect and adapt, resulting in reduced risk and better alignment with customer needs.

 

Do you have a story to share that your team crafted well and delighted the customer?

Becoming User centric with User Stories

Becoming User centric with User Stories

storytelling user story

Traditional product development creates functional barriers that separate the product developers from the users of the product. The reason user stories were used in the Extreme Programming was to connect the product developers with the real-world stories of the customers and users. Stories help the developers understand the pain areas of the users and the opportunities of delighting the users and making them feel awesome.

Today, for most of the teams, User Stories have just become a form in an electronic tool which someone should fill in so that it can enter the Sprint planning, get developed and shipped. Instead of learning the art of storytelling, Product Owners and Teams are often found searching for the perfect ways to fill the User Story templates . In this process, the real intent of the user stories is somewhat lost.

To benefit from the User Stories, teams must go back to the original intent of connecting with the users and learning the user’s latent pain and gain areas, understand their emotions and how a product can help make users’ life easy.

Medtronic, a Minnesota-based medical technology company has institutionalized the art of this storytelling. Every year at the annual employee gathering Medtronic brings in users to share their life transforming stories with all the employees. Leaders at Medtronic use every opportunity to share User’s Stories in their messages. They use both positive and negative stories to reinforce to employees its guiding principle of “Customers First”.

User Stories help product developers understand the impact they have on the people they serve. Understanding the story of the users also empower the developers to find the best way of solving a challenge.

User Stories act as a bridge between users and product developers.

User Stories are most popularly used today in the Agile software development field particularly with the Scrum Framework.

Often index cards are used to write User stories that focus on the benefit to the user. It consists of one or more sentences in the everyday language or the language of the end user (user perspective) that captures description of the story and benefit to the user. It also captures criteria for its acceptance. It helps in shifting the focus from writing about requirements to discussing about the benefits to user(s).

User story card captures the ‘why’, ‘who’ and ‘what’ of a potential feature or hypothesis in simple and concise way. Often limited to detail which can be hand-written on an Index card.

When used with Scrum Framework, a user story should essentially will be small enough so it can be delivered within one sprint and valuable enough so that a user can use it and provide her feedback.

INVEST

Bill Wake came up with INVEST acronym to emphasize what makes up a good User Story:

 

 

INVEST

I – Independent

N – Negotiable

V – Valuable

E – Estimable

S – Small

T – Testable

Independent

User stories are easiest to work with if they are independent i.e. it shouldn’t overlap in the concept. The team may creatively break the technical dependencies as often as possible to create independent stories.

Negotiable

A good user-story should be negotiable. It should capture the essence of the requirement and not the detail hence allowing the team and the Product Owner to negotiate the scope and approach of developing it.

Valuable

A good user-story needs to be valuable to the customer. It should clearly answer the “why” so the resulting product increment becomes valuable for the user an essential condition for a user to be able to use the product and share feedback. This criterion also draws attention to avoid creating stories that does not deliver customer value such as – story that only focuses on single function such as database work, or platform enhancement or only UI tasks.

Estimable

A team should understand the story well enough to be able to estimate how much time, effort will be required to deliver a testable and acceptable feature. The estimates allow the Product Owner to forecast the budget and delivery timeline.

Small

A good story typically represents at most a couple of person-days’ worth of work. If the work exceeds a week, the team may have difficulty in delivering a user story hence running into the risk of not delivering it within a sprint. Delay in delivering the user story delays the feedback again increasing the associated risk of failure.

Testable

A good user story is testable, i.e. everyone should well understand how the completion of the story will be verified by a user or a proxy of the user that is a Product Owner. It should be understood well enough so that tests can be written and performed. Acceptance Criteria helps establish this user acceptance testing. In case if a story can’t be tested, its scope should be reframed in a way so it can be tested.

Creation of user-story

Once I was coaching a team that was transitioning from traditional product development to implement Scrum. It was their first day after I facilitated a 3 day Agile Team Boot camp for their entire team. Their Product Owner – Jane was excited to get started with user stories and creating their first product backlog. They did have the knowledge that it’s going to be different from their usual approach of writing long multi-page requirements documents. The knowledge had to be put in to practice. Jane and the team members had to cautiously put in efforts to get away from their way of thinking and behaviour of writing long requirements documents and dumping those to their shared document repository and hope that everyone on the team will read, understand and deliver product as intended. That was never the case.

At the beginning of the working session, we did a 2-minute activity to recall points they learned about the User Stories during the boot camp. During this activity, Sri one of the team members stood up and recalled:

A User Story card is a promise for a conversation

Not a mini requirements document, not a requirement itself, a user story card is a promise by the Product Owner for a conversation with the team members when the team picks up a story for implementation. Alistair Cockburn, shares how it was done by the Chrysler C3 team in 1998 when it was first used:

A programmer would pick up a story card, walk over the Customer, and say, “Tell me about this”, then go over and program it up, and come back again and ask, “Like this?”, and back and forth until it was done. The ‘requirements’ were never written down, they communicated in discussion and feedback.

Not writing down requirements felt uncomfortable for Jane in the beginning. Jane and the team members collectively formulated and wrote (new) user-stories. Stakeholders were invited to contribute to writing user stories based on their needs. During the workshop, the intent was to write down high level 1-2 line description of each user need, feature, and hypothesis. There were lot of queries and as we navigated through the workshop, each query was discussed, explored and addressed.

Below I list some of the common User Story queries that I’ve heard.

One of the common way teams write user stories is in the form of:

As a <user type>, I want to <some goal>, so that <benefit>

A crisp user story should answer the following three questions:

  • As a <type of user>: Who are we building it for, who the user is?
  • I want to <action>: What action the user should be able to perform, what is the intention?
  • so that <benefit>: Why are we building it or what value it brings to the user?

 

Three common user story errors to avoid

  1. Missing User: If a story doesn’t specify the user, it is most likely going to miss the user’s story. If there is no user and no story the result is far from being a User Story. As simple and silly as it sounds, this is one of the most common error teams make. You may see it in the stories that say something like – As a DBA, I want to….., As a System Admin, I want to….., etc. It takes cautious effort on part of the Product Owner to pro-actively connect with users, listen to their stories and bring them to the team. Each user story may specifically address one user or a group of users with similar needs. Get this one right and you are on the track.

 

  1. Too much detail: This one is again resulting from the old mindset of writing down detailed requirements. The Product Owner tries to write every detail in the user-story forgetting the fact that a user story is a promise for a conversation not the requirement itself. Too much detail often dilutes the purpose of the User-story and hinders the team members from having the conversation with the product owner. Writing down too much detail in the user story can conveniently hide the fact that users’ input, users’ story has not been considered before formulating the user story. Necessity to write down too much detail may also be an indication of lack of sufficient trust in the environment – often prevailing in the cases where the Product Owner and the team members work from different geographies.

 

  1. Answers ‘how’ and misses ‘what’: A user-story should define what the product should do and what benefit should it yield not the specific approach of how it is achieved. The approach to achieve a user story’s intended outcome should be left for the development team to identify. After the high-level task of writing user stories was completed, the next task was refinement. To refine user stories, split larger stories, add description, write acceptance criteria etc. The team invited the Scrum Master to setup a follow up session to refine the user stories.

 

Subscribe To Our Newsletter

Join our mailing list to receive the latest news and updates from our team.

Awesome. You've successfully subscribed.