What are the characteristics of good user stories?
Using the INVEST approach to ensure that your user stories are fit for purpose
The only real test of whether a user story has been written well is whether the development team is able to pull it from the backlog and begin working on it.
Helpfully, there’s a well known acronym that allows you to “test” if your user stories are ready. Each letter in the work INVEST represents a characteristic of a good user story. It’s worth spending some time understanding these different characteristics as they can make a good checklist for any form of requirements, even if not written in a user story format.
INVEST
You should consider the user story characteristic for each letter in the word INVEST as a proven checklist for good user stories.
I — Independent
The I in Invest stands for Independent
It should be possible to implement each user story independently of others. The idea behind this characteristics is to allow the team to deliver in small incremental steps. In agile thinking, it makes sense to deliver value to the end customer as early as possible.
For example, let’s imagine we are building a system that allows customers to subscribe for information about concert tickets. Our service costs five dollars a month and gives early access to tickets for popular bands. If you have paying customers wanting to sign up for your service, it makes sense to get them signed up as soon as possible in order to start making money.
We could write a user story that says:
As a Customer, I want to be able to register for the tickets information service and be sent my first information email, so that I can see what concerts are coming up.
This would work but is not independent as it has bound the process of signing up for the service to the customer receiving the information email. If we build this user story, the business must wait for both the sign up process and the information email process to be ready before it can get the benefit of the customers’ subscription money. It would be better to write this as two independent stories, perhaps like this.
As a Customer, I want to be able to register for the tickets information service, so that I know I will get information about future concerts.
As a Subscribed Customer, I want to receive my first information email, so that I can see what concerts are coming up.
This gives the business options. For a startup, it may be that getting subscribers registered is much more important at this stage than later stages in the business process.
You don’t want to be hanging around waiting for the additional functionality needed to send concert information when you could be getting the sign up process live and getting paying customers signed up.
Remember, if there is value associated with the user story, the sooner you get this functionality implemented into your organisation, the sooner you begin to collect that value. If a piece of functionality brings in several thousand pounds or dollars of value every month, then every month earlier you can get that functionality live is an extra thousand pounds or dollars that the organisation would not otherwise have appreciated. Similarly, if broken functionality, or missing functionality is costing you money every month, then every month that you delay fixing it is lost money.
Sometimes it’s difficult to build functionality independently, in order to achieve this, the team may need to be creative about how they solve the problems and may need to refactor (or recode) certain parts of the system.
It is generally easier to write independent user stories when dealing with larger requirements; the big blocks, or epics, within a product or service will tend to be more independent as they represent discrete parts of the system. As you develop your requirements at a lower level it is likely that you will find it harder to maintain true independence within stories, remember that we try to maintain independence of user stories to help prioritisation decisions. If you’re struggling to write independent user stories, consider if you’ve reached a natural size for the user story, it may be that there’s little value in breaking down to smaller pieces. At lower the levels, I would advise that you try to keep stories independent but don’t waste huge amounts of time on the activity if there’s little chance that your user stories will be introduced at a different time.
N — Negotiable
The N in Invest stands for Negotiable
When creating user stories, it’s important that there is some level of leeway in the way in which a solution can be created. If you are rigidly writing down exactly what must be delivered, you might as well write a functional specification like we used to do on waterfall projects.
The value of having negotiable user stories is to benefit from the experience and ideas of a wider group of people in the team. In my experience, if you start with a vague user story and have a discussion about who the team might deliver it, you will get better solutions than if you dictate exactly how the requirement must be met. No one person has a complete monopoly on knowledge and opportunities to deliver a better system will be missed if only one person chooses how to build things.
For example, let’s take a fictional product owner’s user story that may be too rigid. Let’s imagine a sales system that allows customers to order concert tickets. In the existing business, customers only order for one concert at a time and they have to complete that process within an hour.
As a Marketing Manager, I want all uncompleted sales to be deleted from the system at midnight, so that the system is clear at the beginning of the day for new sales.
In this example, the product owner has made a big assumption that the best way to deal with the problem of incomplete sales is to have a batch process that looks for incomplete sales and closes them down. This means that the system may require a scheduled script to run against a database at midnight.
If they had written the user story in a more negotiable manner, the outcome may have been different.
As a Marketing Manager, I want uncompleted sales to be deleted, so that the system can make a new sale.
Now the team might naturally discuss different ideas. They might consider the batch process, but also a new process of deleting old sales as a part of the process of starting a new sale, or perhaps making the system work better with multiple sales for each customer, they may even consider a new business opportunity of allowing the customer to keep a record of their incomplete sales and automatically filling them and offering them to the customer if new tickets become available.
In reality, there are often more than one way of meeting a requirement, so why wouldn’t you want to consider a wider range of solutions than one person can think of?
V — Valuable
The V in Invest stands for Valuable
This characteristic of good user stories is all about “so that” part of the template. This part of the user story encapsulates the value that the end user will experience when they can use the functionality. A user story should also deliver some business outcome that is desired by the organisation.
For example, let’s look at the following story
As a frequent flyer, I want to collect a point for every mile I fly, so that I can collect enough points to get rewards.
This user story delivers a clear “so that” reason for the story, but there is a business value for this as well in terms of encouraging customer loyalty. The product owner should understand the business value that he or she will release with each user story. In reality, it’s unlikely that business value will be tracked at individual user story level but each story must be concentrating to the organisation’s goals.
E — Estimable
The E in Invest stands for Estimable
A user story should, by the time it’s been discussed or refined by the development team, be understood enough for the team to be able to estimate the complexity and level of effort needed to deliver the functionality. Remember, user story should, by the time it’s considered done, form a potentially releasable element of the overall functionality.
In scrum teams this is important so the team doesn’t over-commit when pulling work from the backlog. However, regardless of the methodology used, user stories should generally be kept to a manageable size and as small as is usefully possible. One non-scrum agile team I worked with had a self-imposed limit that no user story should take longer than two days to deliver; this meant the team needed to understand enough to be able to stay within that limit. This emphasis on understanding was, in my mind, was much more valuable than formal estimation.
The user story needs to be understood just enough to allow the scale, scope and complexity to be loosely estimated, it doesn’t have to be completely understood and specified. This best practice is not about identifying and announcing delivery dates, instead it’s all about reducing the risk that the development will get into difficulty as unforeseen complexity is uncovered.
S — Small
The S in Invest stands for Small
In a Scrum project, the functionality associated with a user story should never take longer than one sprint to deliver. It’s too easy to end up with large user stories that take multiple sprints to deliver. In this case, the best practice of having a potentially releasable increment of the overall system at the end of each sprints begins to unravel and delivery risks begin to multiply.
When writing user stories, larger stories should be broken, down into smaller stories wherever possible in order to reduce the delivery risk for each part of the system and to increase the team’s delivery flexibility. We’ll cover some strategies for splitting user stories later on, but for now let’s just say that small stories are generally easier to deliver and therefore better than large stories, as long as the smaller stories still follow the Invest principles.
It’s easy to think of big user stories that delivery lots of value that end up cutting through all parts of the business, much harder to deliver in smaller bits. Teams need to work hard to break things stories down into deliverable elements.
For example, if we need to create an interface that moves customers from a sales system to an administration system, we might start with the following user story;
As Sales Administrator, I want customer and sales information transferred from the sales system to the administration system, so that the customer can be sent their order.
Just looking at it, I’m beginning to think that this could be a large piece of work.
It’s okay to start with a place-holder requirement to build the interface but the product owner or business analyst should work with the development team to come up with strategies to break the placeholder into smaller pieces.
For our example interface, it may be possible to start with passing the simplest record type between the systems, perhaps a sale of a single item. Once that initial version is build, it should be possible to broaden the requirement in subsequent stores to and then adding in complex records. Following this strategy, we may end up with the following stories, each of which should be smaller than the original.
As Sales Administrator, I want single item sales for existing customers transferred from the sales system to the administration system, so that I can send them their item.
As Sales Administrator, I want multiple item sales for existing customers transferred from the sales system to the administration system, so that I can send them their item.
As Sales Administrator, I want new customer details transferred from the sales system to the administration system, so that I can send them their items.
As Sales Administrator, I want the details for existing customers with new addresses transferred from the sales system to the administration system, so that my records are updated and I can send them their items.
By breaking the larger story into smaller pieces, you can see how you could build the interface in a series of smaller stages. This allows the team to be worrying about less detail at each point and for the testing to be handled in smaller chunks. Handling one smaller story at a time should reduce the overall risk of delivering the functionality.
Importantly, each one of these split stories could be delivered at a different point, giving flexibility to the business. Here’s an example of how splitting the big user story above into the smaller ones could pay off.
Let’s say that it becomes important to update existing customers’ addresses in the next few weeks, perhaps due to a postcode or zip code change. We could run an upgrade script to change the addresses on the sales system database and the administration database, but if we build the final story, we only need to update the addresses on the sales system and let the interface take care of updating the administration system. This option might not be available if the team thinks they have to build the entire interface for all scenarios before it will work.
T — Testable
The T in Invest stands for Testable
The final element of the Invest acronym is that user stories should be testable. Everyone in the development team, not just the testers, should understand how the functionality will be proven. This could be formal software testing, user acceptance testing, sample testing, a demo of the software or some other form of verification.
The important thing is that the team must understand what constitutes “done” for each user story before they start development and they must be confident that the level of testing is appropriate for the user story.
It is good practice to specifically talk about the way in which functionality will be tested as this can often reveal important aspects to the solution that would not otherwise have been considered. The question “how do we prove that this is working as expected” puts a spotlight on the solution in a way that a conversation about development will not as it’s impossible to gloss over the details. I was working on a system a couple of years ago that included a rudimentary customer and account search function; it was only when we discussed how we would test the functionality that the complexity of the different options we were considering came to light.
If you found this article useful, you might be interested the book it came from. In “Effective User Stories”, I explore user stories in more depth, work through specific examples and include loads of lessons I’ve learnt over the last 20+ years. You can find the book here.
