The Art of Co-Creating Great User Stories
By: Vishal Soni
Tags: Agile Methodology, Product Design, Product Management, Product, User Stories

The Art of Co-Creating Great User Stories

Create great user stories (copyright — Vishal Soni)

User stories are an integral part of a Product Manager’s life. User stories are a very powerful tool for capturing the customer need, specifying the actors involved, validating the benefits, detailing out the customer journey and tracking the priority. If written well, user stories may be all that would be needed to develop a product.

While the user story format has been standardized to a great extent, the process of creating them — not so much. The process of user story creation is extremely subjective, and differs from PM to PM. Some PMs prefer to write a so called BRD first; which then they convert to user stories, while others dive directly into story creation. Some prefer to keep them extremely high level and then elaborate them with the dev team, while some detail them out to the last possible alternate scenario before sharing it with the teams.

I have personally experimented with a lot of different approaches myself, and while this largely depends on personal preference and comfort, I do believe some approaches are more efficient than others. The aim of this article is share one such potential approach.

Step 1: Create a Product Alignment Document

This document is known by many names. Feature brief, One pager, etc. I like to call it, the ‘Product Alignment Document’ — because that’s what it is for.

The motive behind creating a Product Alignment document is simple — to allow the PM to conduct the initial exploratory analysis and document it in a format which helps gathering feedback from the rest of the product team, while building a shared understanding amongst the team.

The format for a Product Alignment Document should be as follows —

Product Alignment Document (Copyright — Vishal Soni)

Problem Statement — This is where the actual problem statement that is being addressed by the feature should be captured. The sad reality is, generally PMs don’t spend enough time thinking over the problem statement. And this eventually leads to spending too much effort solving things that were not a problem to begin with. This section is aimed to help them do exactly this — evaluate the problem statement in greater detail. Why do we need this? — While the problem statement captures the WHAT (what is the issue?), this section captures the WHY (why is it an issue / why do we need to solve it?) Success Metrics — This is to capture the success metrics related to this feature — essentially showcasing the benefits of the feature implementation. OKRs — Most product teams now follow the OKR methodology (Objectives and Key Results). If you are one of them, then you should have the OKR linked per product alignment document. This helps in ensuring all work being done is aligned to the objectives. Solution Direction — This is where the high level solution details are captured. Try to not spend too much time detailing the solution at this stage, as it is bound to shift basis the feedback from other product team members. Rejected Solutions & Why — As the product grows, team grows and team members change, the product entropy sets in. Some of the knowledge related to why certain decisions were taken and whether alternate approaches were explored or discussed gets lost. Also, capturing information about which solutions were discussed and then rejected and for what reason is a great way of ensuring all possible alternatives were considered. Questions — This is where the PM can list out the questions he/she wants to ask the broader group. Questions can be for problem statement validation, feedback on the solution direction, recommendations on other alternative approaches, etc.

Step 2 : Product Alignment Session

Once the product alignment document is ready, these should be presented in a ‘Product Alignment Session’.

How to run the Product Alignment Session -

This session is typically conducted within the product team i.e. with other product managers, technical writers, product evangelists and designers.

The meeting is generally for an hour or hour & half. Do not dive too deep into the solution framing or discovery, as the goal is to validate the solution or the opportunity amongst the product team and get the questions listed in the document answered.

Discussion per item should be time boxed to ensure everyone is able to cover all topics.

Expected output from the meeting -

Expected output from the meeting would be an alignment and agreement from the product team on the roadmap item. It would be something like -

“Please proceed..” or

“We should also look at these points first, then proceed…” or

“Lets do more analysis before we work on this..”

Step 3: Create the Visuals

I believe this is the step that gives some PMs an edge over the others.

Humans understand concepts better when explained visually, and hence having some form of visual representation of the feature is extremely important.

I personally love to deep dive into the finer details of UX. So I generally prefer to design mockups (hi-fi where possible) for single screen features, or clickable prototypes for multiple screen features.

There are plethora of tools out there which can help you build prototypes with minimum effort. These are the ones I have used — https://www.axure.com/, https://www.avonni.app/ and https://proto.io/.

Image Credit — Proto.io

Step 4: Create the draft User Stories and validate the feasibility with development team

A lot of PMs tend to skip this step, as they prefer to do it as part of the user story grooming/refinement session. While that is not wrong, separating out feasibility analysis from grooming/refinement session provides considerable benefits in the overall scheme of things.

This helps ensure the user story that you create is aligned with what is technically feasible. In case the solution needs to pivot due to feasibility issues, you can tackle it early on.

At times, the Tech lead would need some time to assess the feasibility. This will provide him/her some time for the same.

The Tech lead will have enough background to navigate the technical solution discussions during the grooming/refinement sessions.

This eventually also helps in better user story estimation (I have personally noticed the disparity between estimated versus actual reduce)

Step 5: Groom/Refine (Finalizing the stories and Sizing it)

After the feasibility assessment, the user stories are now ready to be discussed with the sprint squad (development team). This is when you firm up the stories, cross the t’s and dot the i’s and size the story for effort.