User Stories – 5 simple hacks!

Stories. You probably have tons of them if you are a?Product Manager, a Product Owner, or a Business Analyst. Why? Why should we have to tell good stories? That should be left to the likes of George. R.R. Martin or Harper Lee, right?! Well, no, not at all.?

We are all storytellers in one way or another, and telling a story about your product is how you can help your team understand your users' vision and objective. And like any good storyteller, you need your stories to be clear and impactful.

In case you want to check out my previous posts -?BA-1,?BA-2,?PM-1,?PM-2, PM-3

What are User Stories?

User stories are short, simple feature descriptions?told from the perspective of your users and customers. The main aim is to put end-users in the center of conversation and capture product functionality from their perspective. Thus, developers get a better understanding of what, for whom, and why they’re building.

Hack #1: Keep it short and simple

Write your stories so that they are easy to understand. Keep them simple and concise. Avoid confusing and ambiguous terms. A simple format which can be used -

As a?<user role>,?

I want?<a feature>,?

so that?<some benefit>.

Example - “As a customer, I want to browse T-shirts by sizes, so that I can quickly find what I’m looking for.”

This format is quite effective. For one, it puts a product or a user requirement into the first person—meaning you’re thinking about the?actual person using it, not just what needs to be done. Second, a repeatable template is easier for?feature prioritization?as you’re not comparing apples to oranges.

Hack #2: Conversations > Complete reliance on tools

If a team member starts working on a user story and the team has not had a conversation about it, then?you’re doing it wrong!?

Agile principles mention - Individuals and interactions?over processes and tools.

That means discussing the backlog items before unleashing the team on them. You need to make sure that the buck doesn’t stop at putting up requirements in JIRA or Miro (or any other tool). For each user story, you should have a conversation about planning and backlog grooming discussions.

Hack #3: Start with Epics, and break further

What’s an Epic? - An epic is a?big, coarse-grained story. It?has to be broken into several user stories over time. You can think of it as a placeholder for proper, detailed user stories.

Starting with epics allows you to sketch the product functionality without committing to the details. Then you can further break your epics into smaller user stories until they are?clear, feasible, and can be tested.

Hack #4: Precise acceptance criteria

You have your user story, but how do you know when you met the goal stated in the user story? Acceptance Criteria defines how a particular feature could be used from an end user’s perspective.?These?are unique to a user story and form the basis of user story acceptance testing which establishes the conditions for the success of the feature.

Example:?As a photography course attendee, I want to register online to register quickly and cut down on paperwork.

?The acceptance criteria for the above example could include:

1. An attendee cannot submit a form without completing all the mandatory fields.
2. Information from the form is stored in the database.
3. Users can pay by?credit card or debit card.
4. An acknowledgment email is sent to the attendee after submitting the form.

So, as you can see, you write acceptance criteria in simple language, just like the user story. When the development team has finished working on the user story, they demonstrate the functionality to the Product Owner. While doing this, they show how?they have satisfied each one of the criteria.

Hack #5: Invest in good user stories

Bill Wake came up with the INVEST acronym to help us remember the attributes for writing effective user stories: Independent, Negotiable, Valuable, Estimable, Small, and Testable. It helps you validate if the user story you have written is a good one.

Storytelling is an important and often overlooked part of a PM's or a BA's job. The more the visibility and accessibility of these stories, the more the communication and collaboration; which eventually leads to a faster velocity in a timeboxed sprint.

User stories have helped shift the focus from writing long business requirements to talking about them!

What are your views? What are some of the good hacks or tips you think can help a storyteller?