For people working in Agile software development, A User story is perhaps a familiar word. While it might sound easy, and people could think that a user story is about describing the “What” and then doing it, it is evident from practical experiences that “What” is an abstract term. People use the user stories for a variety of stuff. There are different thought processes on what the User stories represent, and each of them is right in its own accord. But if we look at the fundamental intention of creating user stories, we can understand that they are for communication.

Stories aren’t a written form of requirements; telling stories
through collaboration with words and pictures is a mechanism
that builds shared understanding.

Stories aren’t the requirements; they’re discussions about solving
problems for our organization, our customers, and our users that
lead to agreements on what to build.

– Jeff Patton

The word “Story” indicates that the connection needs to be felt by everyone involved. It’s about telling and asking. Imagine someone writes this user story: “Jon Snow should be able to find dragon glass so that he and his army can kill white-walkers” (Sorry, here’s another Game of Thrones fan. Couldn’t help it). Of course, several resources could be put at it to fulfil that ask. But it’s only a part of the big picture. We do not know many things like:

• Who Jon Snow is
• What his capabilities are
• Why he wants to kill white-walkers
• What a white-walker is
• When he wants to kill
• Where the dragon-glass can be found
• Why dragon-glass

Of course, all of these cannot be written in one place as that could lead to huge documentation and defeats the purpose. But, as I state, it’s *documentation* and not a story in the software world. Then how do we go about it, given it’s the only opportunity to manifest the information?

3C’s of a good story

In 2001, Ron Jeffries had named 3 aspects of a good user story. They are Card, Conversation and Confirmation.

• Card — to be used as the placeholder for written information. Absolutely minimal inputs may be present in this.
• Conversation — this is where majority of the action lies. Everyone participates, gets the rationale, and understands where it fits in the grand scheme of things. Finer details are flushed out and doubts are clarified.
• Confirmation — It’s the final straw in the process. This brings everyone on the same page and determines when the given user story is deemed complete.

In summary, the written description is only a part of the story, and it’s the most visible aspect. However, the important parts are the conversations between the team and the customer representative to understand the details and real value.

How to write good user stories?

The User Stories should be written in a business language to make them easy to understand for the actual users and stakeholders. In addition, to make it easy for planning and implementation, stories should have certain attributes. To aid this, Bill Wake suggested a good way of creating user stories with INVEST criteria.

Independent — to minimize dependency between multiple stories from an implementation perspective. For example, Clinicians should be able to access patient information in the ODL module after onboarding. For this, the patient should be onboarded first. And the story could be split accordingly.

Negotiable — The stories can start with some details, but they should be open for negotiation. There could be scope changes or other changes that might have a significant impact. If stories are negotiable, they can accommodate such needs. For example, A user should be able to pay for insurance with any credit card Vs A user should be able to pay for insurance with Visa and Master cards since the customer doesn’t support Amex.

Valuable — The outcome from the story must be valuable. It could add value to the customer, user or the organization. But, the ultimate aim is to convert the output to an advantageous outcome. For example, Admin should add multiple users to the system through a CSV bulk upload to save time.

Estimatable — The story should be done in a finite amount of time. If there are too many complexities or unknowns, even a guess could be difficult. For example: Implement a solution for identifying the virus variant within 2 hours of sample collection. But, again, there are too many variables in this.

Small — There is scope to chunk one story into multiple stories. If it is too big, it could take a long time to be completed. The priorities could be set accordingly. For example: Accepting payments on the website could be chunked to Accepting payments on the website via COD, Accepting payments on the website via wallet, Accepting payments on the website Via Debit card, Accepting payments on the website via Internet banking etc.…

Testable — If a user story cannot be tested, how does the business understand if it meets the expectations? To be able to make a story testable, the key is to use clear terms. Abstract usage cannot yield any results. For example, the user should not wait for too long at the entrance. The user should not wait for more than 2 seconds at the entrance.

Some examples of good User stories

As a trainer, I want to email selected participants to inform them about the prerequisites for the class.

As a learner, I want to subscribe to the newsletter by providing an email address to update the latest blogs and articles.

As a patient, I want to access the clinician’s shared google calendar to book an appointment.

As an Administrator, I want to order Medium licenses for all my users using my Visa credit card to get licenses at a reduced rate.

As a trainer, I want to get feedback on my class through a survey to improve the learning experience for future trainees.

As a prospective buyer, I want to view the broker’s ratings to decide which one to go with.

Now that we have some idea of better user stories, here are some tips to ponder upon:

• Write stories for sure. But make it a point to talk about them.
• Create and finalize stories collaboratively.
• Keep the user (/role) in mind, always.
• Story format helps. But prioritize communication over specific formats.
• Discuss through personas.
• Check for relevance and priority.