User Stories for Dummies

You're not alone if your user stories are sitting "In Progress" for most of the sprint and the delivery isn't happening the way you wanted it to be.

This is a common problem being faced by those who are passionate about building great products as well as for those who are handed an opportunity. Here is a jab at outlining what may look like a same-same-but-different style of writing user stories that is focused on increasing the speed of one thing and one thing only - delivery!

What are User Stories?

Say you're building a software that allows users to exchange messages using a website. If we go by the definition, a user story is an end goal - the smallest unit of work expressed from the software users perspective, hence a basic story for your messaging software may be "AS A customer I WANT to do/access something SO THAT I can get value".

Above is a simple representation of how you can break a software (like our messaging platform) in to Themes (say User Acquisition, Messaging) into Epics (say Authentication, Send Message), and Epics into Stories (say Sign Up Page, Validate Message) and then finally Stories into Tasks (say Email Sign Up, Detect Links in Message etc.). I personally hate using tasks and believe it's wiser to keep stories small, but that's me and you don't necessarily have to do what I do.

3C's of a User Stories

3C's is a great framework to remember while creating or validating user stories. Here is my version of the 3C's.

1. Card essentially is either a physical card the story is printed on or a card in the software having a unique number to it.
2. Conversation is the "AS A Customer I WANT a sign up page SO THAT I can set-up my account" which is essentially a starting point for the team to get together and discuss what's required to get it done.
3. Confirmation is essentially the acceptance criteria which at a high level is the test criteria confirming that the story is working as expected. Example of an acceptance criteria could be "The user gets a confirmation email on sign up". Please note that acceptance criteria cannot contain basic elements like code reviews and testing etc as these are not negotiable.

So I got a story, what next?

1. Once you have a story, the next step is to discuss it with the team and make sure it's got enough information for everyone in the engineering/design/testing team to be estimable. Tip, if Product Owners/Managers and Scrum Masters in your team are participating in the estimation of stories, you're doing it wrong.
2. Once the information is there, get a estimate on how much effort it takes to get a story done. This can be tricky if you just ask "how many days?" - the idea is to ask the effort it requires compared to another story (potentially recently completed). Example, if the story just completed was 3 points, what's this new story worth compared to the one completed? Here's some information on User Story Estimation from the horses mouth that you may find useful. Tip, it's a good idea to have a chart of a few completed user stories and their points next to them on a wall in the estimation session so people can estimate with context.

What's the benefit of writing good user stories?

Writing good user stories will help you to generate traction, achieve business outcomes, get team engagement, bring users closer, boost transparency, foster collaboration, manage expectations through shared understanding and most importantly have fun.

If you're purely in a delivery setup (not as much fun), you may just want to release as much as possible and on the other hand if you're in a discovery+delivery setup, you may want to release a little as possible; whatever be the case - good user stories are the key to achieve outcomes prioritised by risk to the business or value to the users.

Common Problems in User Stories

Meticulously working on stories to make sure they have all the requirements from the business or customers is just one tiny-little part (of many) needed to achieve movement on the board. Here are some of the common areas-of-improvement you may find in your user stories - if you were to look carefully.

Your user stories need improvement when

• a story independently does not deliver any value to the end user.
• a story does not deliver any value to the end user.
• a story lacks a clear goal or analysis depth.
• a story is merely a technical task written as a story.
• a story is missing acceptance criteria.
• a story is either too big or too small.
• a story is trying to provide multiple items of value.
• a story does not have a clear user defined.
• a story is too rigid that it stops innovation and creativity on its tracks.
• you or the business start blaming user stories.

Too much? Well, while stories are the building blocks of a great product or service, it becomes extremely important to make sure there is some sort of consistency in size, analysis and value at the very least if not all of the above.

Creating Good User Stories

A user story is an opportunity to have a future conversation about what the users need. There is no one person that should be writing stories - the whole team should feel empowered to write a stories and share them with the team for feedback.

A Good User Story

A good user story is user-centric, estimable, testable and complete enough to provide a user with some value (often through a specific functionality) once it's done.

Key Definitions

There are 2 definitions that a Product Owner creates with the team and always keeps these handy or sticking at a place highly visible to everyone.

Definition of Ready (DoR) It is a working agreement between the team and product owner on what readiness means or in other words a way for a product owner to indicate an item in the product backlog as ready to work in sprint. It helps measure the ready state of items in the backlog and reduce the pressure on the team to commit to estimates before stories are ready i.e. meeting the DoR.

• Sample: A story is ready to be picked up by the team when it has a definition, acceptance criteria, design artefacts attached (if needed), estimation and there is no outstanding question remaining.

Definition of Done (DoD) Done means every task under the user story (or the user story itself) has been completed and any work created is attached (or linked) to the user story (or in comments) so the product owner can review it and make sure it meets his or her expectations.

• Sample: A story is done when it's coded to standards, reviewed, implemented with unit Test-Driven Development (TDD), tested with 100 percent test automation, integrated and documented.

With these key definitions in place, you can always nurture your stories and get traction on the board, both physical and digital.

Scenarios

In the age of behaviour driven development (BDD), scenarios in acceptance criteria become key to the success of the story. Here is a common framework that works like a charm for writing scenarios in acceptance criteria, GIVEN some context, WHEN an event happens THEN an outcome is observed. This can be extended like, GIVEN some context AND and event happens, WHEN another event happens AND some additional context THEN an outcome is observed AND another outcome is triggered.

These scenarios add a lot of value to your acceptance criteria giving the developers more understanding on how their code has to work with change in behaviour of the users using the product or service.

Do you have any other tips?