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 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 deliverying 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 in to 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, inharently 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 AgileTeams 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 allows 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 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 does 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 create 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. The most effective tools – Index Cards and Sharpies are not meant for writing 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.

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:

  • Is getting these user story benefits realistic?
  • 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!!

The Scrum Master as a Servant-Leader

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

How to grow your leadership impact?

One of the essential aspects of being a leader is that you constantly reflect and adapt your leadership impact on the people you lead. Evaluate...
Read More

Top 21 Scrum Master skills

The use artificial intelligence in product development and corporations is growing significantly. With the help of AI we'll be able to automate many...
Read More

6 Benefits of Good User Stories

Crafting good User Stories is rewarding. Understand the fundamental benefits of crafting good User Stories. Turn these user story benefits into your team’s competitive advantage. Take the assessment at the end of this article. Here are 6 User Story Benefits:
1- Highest Value Delivery
2- Fosters Collaboration
3- Brings User Closer
4- Building Blocks of the Product
5- Boost Transparency
6- Share Understanding

Read More

Essential Building Blocks of an Agile Organization

Creating cross-functional and self-organizing Teams is one of the essential element of building an Agile Organization.

Both aspects require significant effort & focus. These also don’t happen naturally, particularly in organizations led with Industrial Age style of organizational structure and management.

Scrum identifies these as essential aspects and recognizes a specific role – Scrum Master to be responsible for helping the teams and organization achieve Self Organization and improve cross-functionality.

In fact, Scrum Guide specifies it as the first aspect of the Scrum Master’s service towards the Development  Team.

The existence of organizational power and authority significantly limits the potential of self-organization, hence the Scrum Team is designed to not have any organizational authority and power by any of its members.

The Scrum Master doesn’t carry any authority and organizational power, as well as commits to serve the Team’s agenda. Any Scrum Master that doesn’t explicitly let go of authority and power, and does not commit to serving the team’s agenda, would counter to one of the primary purposes of the Scrum Master role. Such situation is not Scrum, as the organization won’t fully realize the intended benefits of implementing Scrum.

How to write Good User Stories?

storytelling user story

Why care for writing good User Stories?

Good User Stories are easy to understand and implement. Crafting valuable and small user stories could in most cases solve the biggest challenge of Scrum Teams – delivering shippable product increment every Sprint.

Mastering the art of crafting good user stories isn’t easy.

When crafted well, good 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 / Business Team would write a requirement they want to be implemented and the team would simply implement it, to the extent they understand it. The User Story challenges this rationale. 

It requires identifying who (a user) exactly will use the feature being asked to develop and specifies what benefit the user will get. This helps remove ambiguity and offers clarity in understanding the User’s story.

As discussed in my article becoming user centric with User Stories – A User Story is a promise to further communication that should happen between the Product Owner and the team to create a shared understanding of the story of a user. A user story card may outline “why” – the benefit, “who” – the user and “what” – the feature or action.

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

What makes a good User Story?

In order to understand what makes a good User Story, it is important to understand what the User story means for everyone involved in creating and implementing it.

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 in 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, 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 start helping the Scrum Team to write detailed user stories (kind of mini requirements documents), police around to ensure the electronic tool is filled with all 16 types of user story fields, detailed descriptions are written and every possible acceptance criteria are listed.

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

Traditional mindset, lack of trust in the work environment, geographical distance between the PO and the DevTeam, and client-vendor setup, all such factors encourage writing detailed requirements.

The Scrum Master should be able to pick up early smells and help the Scrum Team avoid falling into such trap.

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 User Stories a logical fit (as a practice) with the Scrum framework.

A simple User Story template, widely used by Scrum practitioners involves these three elements:

As a <<USER>>,

I want <<FEATURE>>,

So that <<VALUE>>.

This simple template narrates the value for the User. The primary focus of the User Story written using this template should be the Business Value that the Product Owner is trying to achieve by having the User Story implemented.

How to write a good User Story?

 

Here are three characteristics that help craft a good User Story.

1. Identify the Business Value:

To make a product successful, the Product Owner tries to maximize the business value being delivered by the User Story. In order to maximize the business value, its important to first identify whats the Business Value that the team is trying to achieve by implementing a User Story and all the effort that goes around it. Understanding the Business value also helps the Product Owner to prioritize User Stories and have the User Stories 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

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, step-by-step and the above User Stories are evidence that the Product Owner writing the above 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:

User Story Example 5:

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

   I want to be able to buy 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 the 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 craft 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 is being targeted. Many Scrum teams use User Personas for their product and specify a particular persona for each user story.

Example: I had once worked on a capability that was available for 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 and Mobile users.

The team started with this format:

   As an App user,

   I want <<FEATURE>>,

   So that <<VALUE>>.

Now we had an option to split 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 split the user story as an “Andriod Mobile App user” or “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, 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 of 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 into what’s being sought. Each User Story was crafted in a way that it could be implemented within a Sprint. Breaking it down to the specifics removed ambiguity.

In summary, nailing the “who”, “what” and “why” of the User Stories, making them transparent, valuable and small makes them viable survivable experiments for the Scrum team. It allows 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?

Subscribe To Our Newsletter

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

Awesome. You've successfully subscribed.