Uncovering Scrum Myths: User Story

Are you new in the IT industry and scared of some unknown phrases and weird slang? Or you have longstanding experience as a software developer but you want to refresh your knowledge? All reasons to learn something new are good! Let's see what the most common misunderstandings in software development world are these days. All myths needs to be uncovered! At the beginning let's talk about User Story. In my day to day, I see quite often that user stories may bring a lot of confusion even for qualified professionals. Product Owners tend to create them in either too detailed or too laconic a way. Developers working with user stories usually think technically and forget about business context. Testers are in very straitened situation trying to test badly prepared user stories. That's why I think it's useful to recall what user stories really are and what you should pay attention to when you create them.

User what? What on earth is a User Story?

To be as simple as possible a user story is just a way of storing and presenting requirements. It's a very clear and flexible way. As agile methodologies are getting more and more prevalent, there is a need to have agile tools as well. In an uncertain environment when you need to follow customer needs, it's really important to have flexible tools that allow you to quickly react on changes. That's why lightweight user stories fits better nowadays than chunky formalized documents (and formalized approval processes coupled with them!) that were still popular not so long ago.

What makes user story good?

There are several conditions that should be met to consider a few lines of text you has just written as a good user story. First of all, think about business value. Why does the customer want to pay you? Because your software will solve their problem! So basically solving problems gives your customer some value. We can then say that Business Value is every reason why your customer wants to pay you. It can be either increasing profit, reducing risk, making employees feel better or some other form of needs and expectations. Every good user story should bring Business Value to your customer. Otherwise your effort will be wasted. The next thing that should be assured for each user story is independence. The development team needs to be able to pick up a task and start working as soon as user story is added to the sprint. In my experience I have seen a lot of frustrating situations when one user story was dependent on another one. The team wanted to start working but were blocked. The best way to not block the work of your team is to think about dependencies before you even start creating your story. The earlier dependencies are solved, the more efficient your team can work! And the last thing user stories should be based on real life scenarios. The worst thing that you can handle during development is working on a scenario that makes no sense or couldn't happen in real life!

Okay, but what should a User Story look like?

The main idea behind user stories is to define one scenario of user journey in the system. That's all! To make it more readable we can give it a structure. The most popular is the scheme:

As a <role> I want to <some goal> so that <some reason>.

Why is this scheme so good?

• It's easily manageable as all requirements have the same format this is a great benefit when you prioritise features in the Backlog
• It provides a role in the system as you can have different types of users with different needs and different scenarios
• It defines expected behaviour and emphasises the reason why, giving the team a better understanding of the requirement, highlighting value and business benefits and reducing the chance of implementing unnecessary features

How can I start writing User Stories?

I really encourage you to start from defining roles in your system. The role represents a group of users (not to be considered as individuals!) and based on their interests in the system, and what they may potentially use it for. After that, think about the effect you want to achieve. Why is more important than what. When you know who the subject is and what motivations are, take piece of paper (e.g. sticky note) and start writing. Sticky notes can be easily stuck to the board giving you possibility to organize them in prioritized backlog. You can also use special online tools for storing user stories (to mention a few: www.trello.com, www.easybacklog.com, www.atlassian.com/software/jira). Photo: Sample scrum board (prepared by author of this post) with user stories

Wait! Do I need to know what the user wants up front?

No! Consider your user story as a starting point for discussion. You don't need to know everything at the beginning. Feel free to modify your stories every time you have new information, new ideas or whatever! Start from high level and keep providing details over time. The good rule is that stories that are at the top of your backlog (so they are close to being kicked-off) should have more detail, while stories that are not clarified yet and are at the bottom may have just high level descriptions. You will expand them later.

I wrote my first user stories. How can I polish them?

The first step that you can do to make user story better is adding acceptance criteria. That are all things that need to be met to view work as completed. The user story, by definition, is simple and focused on user needs. To make it more readable and substantial for technical people (developers, testers, etc?) consider attaching list of some further, more detailed suggestions. In a form of bullet points, you can encapsulate any more specific requirements:

• All technical boundaries
• All cosmetic details (colours, designs, etc?)
• All non-obvious behaviours
• All very specific circumstances and conditions
• All things that potentially may help in development
• All information needed for testing

A good starting point for defining acceptance criteria is showing the user story to your development team. Answers to all questions they would have will form your first set of acceptance criteria. Please remember that good acceptance criteria should be specific and measurable, so people can rely on them.

The bigger story the better?

The last section of this blog may lead you to think that you should always expand your user story. Is it true? Absolutely not! Developers need to have all non-obvious points clarified to be able to deliver what is expected. But you don't have to swell your story to infinity. Keep it simple! Stories that are too long can become a nightmare. To conclude whether your story is too big or perfect fit try to ask several questions:

• Does the story cover only one particular feature/requirement/user journey?
• Is the story small enough to fit in one sprint?
• Is the story easy to estimate?
• Is the work that needs to be done separable and independent?

If answer to any of these questions is no, that's good starting point to think about splitting the story into multiple stories! How to do it is a topic for another blog post and there is no simple answer, but try to focus on splitting by functionalities (vertically) and avoiding dividing by technical layers (horizontally) to keep user story having business value, being testable and estimate-able. Small stories are easier to estimate, implement and test, giving development team higher chance of completing them within one iteration and giving you more flexibility on prioritizing and planning.

That's all Folks!

Is now another myth uncovered? I hope this article was useful for you. It doesn't say everything and just touches the topic, so I encourage you to explore it further and listen to your teams. People always know what works best for them. If you have any questions or other points of view on creating good user stories, share it in comments. Discussion is always welcome! Bibliography:

• Feli?�ski, Pawe?�. Before the first sprint. Workshop at Agile By Example 2015
• Jarrel, Jeremy. Creating effective user stories. Course on Pluralsight (https://www.pluralsight.com/courses/creating-effective-user-stories)
• Krupa, ?�ukasz. Refine your backlog first. Workshop at Agile By Example 2015