Let’s talk about User Story sizes.
There’s too much mysticism about user story sizes. Here’s my take, complete with audience participation!
Let’s start at the beginning with the basic principles; there is no prescribed size for a user story. You may have team practices and traditions that mean that stories tend to be a particular size, but that doesn’t necessarily translate to other development teams.
Let’s take a look at three examples.
“As an eBay Seller, I want to be able to list my items for sale, so that I can make money and get rid of things I no longer need.”
“As a Spotify free subscriber, I want to be able to create a playlist, so that I can create my own soundtracks that suite my mood.”
“As a Gmail user, I want to be able to mark an email as important, so that I can identify emails that I need to do something about later.”
Each one of these user stories is perfectly valid in their own way but are of very different sizes. The first is a high level story that literally covers half of the entire eBay website. The second is smaller and describes a specific part of the Spotify application but one that will still have multiple bits of functionality within it, for example, adding and deleting a playlist. The final story is a simple bit of self-contained functionality.
It’s perfectly acceptable to have large user stories at some stages of a project. Large stories are very useful for outlining the “shape” of a system, but it is not appropriate to attempt to build software from stories this size. As work progresses, large user stories will need to be broken down into smaller user stories that can be delivered. If the team tries to develop software from stories that are too large and vague, it is highly likely that they will struggle to deliver in a reasonable timescale.
We’ll get into how user stories of different sizes are used in the section on “epics, features and stories” later. For now, just understand that there is no set size or scope for a user story.
Let’s write some different sized user stories
Now, here’s your chance to join in… Have a go at writing three user stories for Google. Make one of them huge, covering the search engine’s main activity. Write another that covers a subset of the site’s functionality; the ability to serve targeted adverts based on what the user has searched for. Finally write a small user story that describes what should happen when a user clicks on a search result.
Don’t spend more than a couple of minutes on this exercise, it’s just designed to get you thinking about how user stories can be of different sizes.
Go on, take a moment and write down three stories, or at least think about what they would be if you had a pen and paper to hand…
You should have ended up with something like this;
“As an Internet User, I want to be able to enter some search keywords and see a collection of search results that match my search terms, so that I can find information on the internet.”
“As an Advertiser, I want to be able to advertise my products as a part of Google search results to potentially interested consumers, so that I can target my products or services at people who are searching for things related to things I sell.
“As a search user, I want to click on a search result and see the relevant website open in my browser, so that I can look at the website and find the content I was looking for.”
How did you do? Don’t worry if your user stories aren’t identical, there’s no right or wrong answer. If your user stories have managed to communicate enough information about what you’re trying to describe then you’ve done okay.
The first user story felt straightforward when I wrote it, but I found the second a little trickier. Initially I wrote it from the perspective of the Google search end user, but then decided that it was debatable that they were the true end user, so I rewrote it from the advertiser’s perspective. Once I’d done this, I felt a bit happier! I still think it’s a bit “wordy”, but I’m happy enough for the purposes of this exercise.
The third story also felt straightforward, but I changed the “So that” section a couple of times. I started by saying that users wanted to get at information, but this implied a certain type of website; as I realised that the users aren’t always searching for information, sometimes it’s just cat videos! I ended up using the catch-all term “content” and felt better about the result.
One thing you will find as you write user stories is that you will often write several drafts before you are happy with the result. Even then, you will probably change your stories as you begin to communicate with a development team about how to deliver the requirement.
Epics, features, stories and more
Here are some terms that you may find used in a product backlog, you’ll find that different organisations may use these phrases to mean different things, but the concepts will be similar. People get really hung-up on these terms, but they can mean startlingly different things depending on the organisation. It’s worth understanding your context to avoid misunderstanding!
That being said, these are the definitions I normally work with and commonly see.
An Epic is just a large user story. It is too big for a team to attempt to develop and it will need breaking down into multiple smaller user stories before it can be developed. Let’s take the example of an online holiday booking system, we might have an epic covering searching for a holiday, another to cover the process of booking the holiday, another for making payments towards holidays and another for adding customer reviews of holidays. It is likely that each one of these contains multiple user stories and is therefore an epic.
Essentially, an epic is just a way of grouping work in the minds of the people delivering the work. If you are working in an iterative way, it’s normal to never finish all the stories grouped as a part of an epic, some just will never be important enough. This means you need to be careful if management get excited about tracking progress against epics by ticking off the user stories that comprise it — you may never reach the end for all the right reasons!
A user story is a bit of functionality that an end user wants. It is small enough and well understood enough that it can be developed by the team. I’ve covered the way in which these are written in other articles, so I won’t get into examples here.
Sizing backlog items is normally one-way traffic; bigger vague stories are broken down into smaller and smaller items until the team feels able to develop them. It’s less common to combine stories to make bigger stories, but it does and should happen. For example, the team may advise that a story has been split down too far or is very similar to another and should be combined so that they can build them together.
Sometimes teams use additional backlog item names to denote other size stories. You will tend to find that epics and user stories are used almost universally in agile teams, other types are less common, but I’ll have a go at defining some that I’ve seen in action.
If you’re using a tool like Jira, it allows you to create specific work item types, so you tend to see a plethora of weird and wonderful terms appearing; my advice is to try and keep it as simple as possible and avoid adding additional types unless you have very good reasons that help your team to deliver the product.
Features are just Epics by another name. They are just areas of functionality that will deliver a goal and will contain multiple user stories. Sometimes features are used as an interim step between coarse-grained epics and end user stories.
For example, let’s take the example of a government system that citizens must use to buy some kind of license. We might have an epic for taking license payments from customers and this may be broken down into features. We might end up with a feature for paying by credit card, another by debit card, another for direct payment from the citizen’s bank account and finally a feature for taking cash payments in government offices. Here the concept of features has allowed us to break down the payment epic into smaller pieces.
The value of this is that each one of these smaller features may be built at a different time, allowing priority functionality to be refined separately into user stories and delivered earlier. Lower priority functionality, such as the ability to take cash payments, can be left until later or not built at all.
“Themes” is a term sometimes used to describe collections of user stories linked by a common characteristic. For example, imagine an online payments system. At various points in the system, the end user’s activity is checked for signs of fraud. It is likely that each one of these checks will be a different user story, after all, each check can be implemented separately, but if we want to talk about all the points where fraud checks take place, we might want to think about them as a theme within the system. Other examples could be an audit functionality theme or a customer communications theme.
Some organisations have introduced the concept of an ‘Initiative’ that can be used to group related epics that work towards a strategic common goal. In a recent project for a bank, one of the long-term goals we were working towards was to reduce the cost to the bank of attracting savings deposits into the bank. If the bank could attract savings deposits at lower interest rates it would mean that when the money was loaned out, the profit margin would improve.
In order to achieve this goal, the business and team identified several epics to create functionality that addressed various parts of the overall problem. This overall goal fits the definition of an initiative.
I wouldn’t get too hung-up on additional terms outside the commonly used epic, features and stories. People will always think it’s clever to come up with new terms that make their work seem special. I’ve recently heard some talk about “sagas”; I guess someone had some time on their hands and wanted to make their project feel a bit more heroic! Quite frankly, unless it’s contributing to putting working software in the hands of your end users, why bother?
Even with the common terms, the difficulty exists that the size and scope is a purely subjective measure and varies between teams and organisations. One team may find extremely large epics help them to shape their product and may break this down into smaller features and then lower level user stories. Another team may find that they are more comfortable with more smaller epics which are broken into user stories with no intervening step. It really does depend on the team and this is totally fine; trust the team to find the way of working that works best for them.
In my experience, working on large and often complex computer systems, I find that epics, features and user stories are the rough units of work that allow me to work effectively with my development teams. I can introduce requirements at epic level, using this as a framework on which to ‘hang’ the lower level requirements. I can take feature level stories into team refinement sessions, often over more than one session, and emerge with end user stories for development. In my opinion, these three levels have a certain amount of utility and everything else is probably just “management speak.”
Often people question the value of working with Epics; they ask why we don’t just define what we want the end user system to do at user story level straight away? Well, the main value of working with Epics is that they allow us to handle uncertainty. We can sketch out the scope of a system using high level stories and can then can work on priority functionality, breaking them down into lower, more deliverable, user stories, whilst keeping less critical parts of the system at Epic level.
Let’s look at another example.
Let’s use the example of an online learning platform that allows users to find courses that suit them, participate in courses by viewing a series of lectures, test their understanding through multiple choice quizzes and then giving a rating out of five for the course.
If you’re in the mood to join in, have a go at writing three user stories at different levels of detail. One that covers the entire system that is being planned from a user perspective. One that covers a mid-level element in the system and finally a small story covering the ability to capture a rating.
For the whole system I’ve gone for;
“As a learner, I want to be able to learn about subjects that interest me, so that I can pursue my self-development goals”
As you can see, I’m not really sure who my users are so I’ve gone for fairly generic name of “learner”. If this was a real project, I would suggest that we need to do some user research here to understand our potential customer base. The only value of the story I’ve written here is to act as a simple goal that establishes what we are trying to build. In fact, it begins to feel close to a mission statement, such as Google’s “to organize the world’s information and make it universally accessible and useful.”
For the mid-level user stories, I’ve created a few stories;
“As a learner, I want to be able to enrol into a course, so that I can begin learning.”
“As a learner, I want to be able to view course lecture videos, so that I can learn about individual topics online.”
“As a learner, I want to be able to answer multiple choice questions, so that I can test my understanding of the course lectures.”
Here I can begin to see the shape of the system appearing and I can see the customer’s progression through their user journey. As I think harder, additional functions emerge, such as those allowing courses to be written, will occur, creating a conceptual framework for detailed functionality to be developed.
Finally, for the small story, I’ve written;
“As a learner, I want to be able to choose a rating for a course I’m enrolled on, so that I can show what I thought of the learning experience.”
The stories we’ve written above represent a slightly artificial exercise; normally you would be taking a high level story, breaking it into smaller functionality and then breaking those into things that can be delivered. At the point when you’re coding you should be dealing with small atomic stories that deliver limited functions that can be built and tested quickly. You should aim for any mid-level stories you discuss to explode into multiple small stories as this is the path to delivering reliably, after all, there’s less to go wrong in a small user story and therefore delivery risks are reduced.
If there’s one message to take away from this article, it’s that there is no pre-defined size for the names people give to user stories. Fancy names won’t make your product any better!
Equally, there’s no right way to represent your backlog; if multiple layers works in your context, that’s fine. If your product doesn’t need or merit it, why bother? Just try to take each user need to a point where your development team are able to develop the functionality in a reasonable amount of time and without exposing themselves to excessive risks. After all, the only thing that really matters is working software in the hands of your end users. Everything else is just noise…