How to write effective User stories?
For people working in Agile software development, 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 variety of stuff. There are different thought processes on what the User stories represent and each of them is right in it’s own accord. But if we were to 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 connect 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 fulfill 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. 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 for manifestation of 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 understand the real value.
How to write good user stories?
To make it easy to understand for the actual users and stakeholders, the stories should be written in a business language. To make it easy for planning and implementation, stories should have certain attributes. To aid this, Bill Wake suggested a good way of creation of user stories with INVEST criteria.
Independent — to minimize dependency between multiple stories from an implementation perspective. For example: Clinician should be able to access patient information in 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 significant impact. If stories are negotiable, they can accommodate such needs. For example: A user should be able to pay insurance with any credit card Vs A user should be able to pay 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 be able to add multiple users to the system through a csv bulk upload so that there is time saved.
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. 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 in the website could be chunked to Accepting payments in the website via COD, Accepting payments in the website via wallet, Accepting payments in the website Via Debit card, Accepting payments in the website via Internet banking etc…
Testable — If a user story cannot be tested, how does 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: User should not wait for too long at the entrance Vs 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 so that I can inform them about prerequisites for the class.
As a learner, I want to subscribe to the newsletter by providing email address so that I can be updated about the latest blogs and articles.
As a patient, I want to access the clinician’s shared google calendar so that I can book appointment.
As an Administrator, I want to order Medium licenses for all my users using my Visa credit card so that I can get licenses at a reduced rate.
As a trainer, I want to get feedback on my class through a survey so that I can improve the learning experience for future trainees.
As a prospective buyer, I want to view ratings of the broker so that I can 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.
