User Story Analysis

Why do we need User Story Analysis?

There are two reasons for all bugs, delays, and frustrations - missing requirements and poor communication.

The user story is a conversation starter. It's not a requirement.

That conversation never happens for many software development teams. We don't know the language and treat user stories like requirements.

The backlog refinements and the sprint plannings are insufficient to make a proper User Story analysis without a practical agenda for each user story.

What is User Story Analysis?

The User Story Analysis board of 6 frames facilitates a neat, structured, quality-driven, yet human-driven and engaging approach to analyzing user stories and building team routines to collaboratively define the expected software behavior as a Team and turn the user story into well-thought-out requirements.

Who should use the User Story Analysis template?

This template is for software development teams working with User Stories, Issues, Product Backlog Items, or any other short form of a statement that initiates the discussion about building a new software feature or modifying one.

When should we perform User Story Analysis?

This type of analysis needs dedicated time. There are several options:

• Once a week

Up to 90 minutes per meeting

Not more than 3 user stories per analysis session

• Daily

20-30 minutes after the daily team meeting

One user story per analysis session

• Workshop mode

For Scrum teams, take a Sprint Break and spend one whole day in 3 sessions x 90 minutes to prepare the top stories ordered in the Product Backlog and expected to be delivered in the Next Sprint.

The User Story Analysis can be combined with Sprint Planning since the Miro board contains a frame to write the Tasks needed to implement the story and cover all the identified risks and requirements.

The critical condition for this approach to work is to analyze user stories that are of immediate priority. Do not spend time on stories that are not expected to be delivered in the next Sprint or iteration.

Tips for success:

Start small with one user story for a 1-hour meeting. Do not rush the first meetings. Get used to the board. Give your Team enough trials to exercise, get used to the practice, and find their way through it.

Adjust, adjust, adjust. Rebrand if you must. You and your teammates need to recognize the User Story Analysis as their integral helper tool that is there for them to save time and trouble.

It's a checklist to guide you through all aspects that need to be considered to reduce last-minute clarifications, waiting times, misunderstandings, bugs, rework, and anything wasteful and stressful in your development process.

Adapt the practice to your Product and Team. It must fit your context.

How to use the User Story Analysis template?

1. Text Analysis

One of the major purposes of the User Story Analysis is to reduce waste, streamline communication and ensure the Team has a good idea about what's coming. How the user story is written is crucial. The software development process starts with the user story. If we want high quality at the end of the process, we need high quality at the start. The user story may be a little vague at this early stage, but it must be precise.

During the Text Analysis, the Team reads the user story as text and evaluates, decomposes and semantically processes it following the checklist:

• Clear

The text of the story must be clear. There's no place for confusion. It must clearly describe what the user's need is and how they want to achieve it.

• Complete

If the user story pattern is not enough to comprise all the knowns about the story and the user, add more content. Do not spare one sentence because it's not in the pattern.

Don't assume you'll have enough time for refinement and clarifications. Write down everything known about what makes the story valuable to the user and the Product, and be thorough about it.

• Compact

Some teams follow the user story pattern. Others don't, and in an attempt to try to tell all the assumptions and make it clear, they tend to write too much vague text that doesn't bring any information about the expected outcome.

Remember, the user story is a conversation starter - it must be Clear and Complete but also Compact. Instead of 200 words, write only a few engaging sentences that inspire the engineers to build the thing, solve the problem, and sparkle the discussion.

• No repetitions

If you stick to the one-sentence pattern, don't mistake tasks, goals and motivation.

For example, "So that I can see the updated document" is not a "goal", and it doesn't clarify the "WHY?" question and does nothing to bring more clarity to the story. It's a repetition of the "task" - "I want to open the documents library."

If you add more text, don't just paraphrase the first sentence in several more and repeat the still unclear and vague words over and over again. This is the worst noise and waste in writing stories. Repeating text is a symptom of insecurity and lack of overview. If you're not sure how to tell the user story, quote your user. Explain how they feel and why they want the feature.

This initial form of requirements must still be well-structured and clean, just as we expect the software to be.

• No scope creep or scope cuts

Don't assume what is and what isn't possible to implement, especially don't assume what will be faster to implement.

Such assumptions lead to unnecessary scope cuts that slow down development instead of speeding it up.

• No superfluousness

Keep it clean.

The story must be inspiring, and fillers are the worse. Watch out for derailing from the main focus of the story. Sometimes a diagram or a mockup can tell much more than the words. Engineers love diagrams, so use them often. They'll streamline the coding and testing too.

Keep the story engaging and not too wordy.

• Well-articulated

Any text you write must be grammatically correct with proper language and style. Know your Team, know your Product, the jargon, the vocabulary. The amount of bugs caused by negligent writing is unbelievable. You don't have time for such bugs, be precise.

2. Context Analysis

Keep asking WHY until everyone can put themselves in your customers' shoes and feel the urge to help them.

3 Whys or 5 Whys, as many as it's needed for the Team to get to the bottom of the user Goal, Need and Motivation. Do we all understand their intentions, feel their pain and commit to healing it?

3. User Visualisation

We are customers and users ourselves. We, involved in software development, are the greatest critics of software. And yet we forget it when we think about our users. As they are aliens, who must be smarter than us, figure out how the thing works on their own, read our minds and do nothing else but carefully follow our main success scenario.

Imagine and visualise your users. Where are they right now? Are they in a hurry? Are they tired? Will they make an error and have to start all over again? What could cause them to get mad at us and uninstall our app?

How do we want them to feel when they use our feature?

4. GNI Q R Analysis

In addition to identifying the user's Goals, Needs and Intentions, think about how the feature or modification to be, aligns with your product vision, technology and business strategy.

Will this feature enable our further development, or it's a high-risk endeavour, but we must make it happen one way or another?

Are we ready for day 1 when it goes live?

What are the must-have quality characteristics of the feature? Where do we need to focus because there is a risk to production health?

5. Quality & Test Analysis

Now that we know what's expected start writing down WHAT you need to test and HOW you need to test it in order to accommodate all the defined functional and non-functional expectations (requirements).

This is the frame to unleash your imagination, think of everything that could go wrong, and prepare for it.

Work on the highest-priority qualities, use cases, and risks.

Elaborate on the expected behaviour and results.

Identify the test conditions and test object - what to test.

Define the test cases and test users.

Plan the test data generation and the test environment setup.

6. Tasks Breakdown

Naturally, the Team is ready to write down how they will implement the user story.

The tasks can be related to all necessary activities and shouldn't be narrowed down to coding only.

Here are the tasks for the entire Team involved in realising the requirement, and could also include Communication, DevOps, Marketing, Testing and UX/UI design, Technical writing or Customer success tasks.

Disclaimer: This method doesn't claim to cover and predict every possible risk about a user story. Its effectiveness comes from its checklist- and wizard-like presentation that allows the teams to remember and discuss vital topics, incrementally increase the certainty about a feature, and enter the development stage much more prepared and confident.