This is an excerpt from my book Fifty Quick Ideas to Improve your User Stories.
Bill Wake’s INVEST set of user story characteristics has two conflicting forces. Independent and Valuable are often difficult to reconcile with Small. Value of software is a vague and esoteric concept in the domain of business users, but task size is under the control of a delivery team, so many teams end up choosing size over value. The result are “technical stories”, things that don’t really produce any outcome and a disconnect between what the team is pushing out and what the business sponsors really care about.
Many delivery teams also implicitly assume that something has value just because business users asked for it, so it’s difficult to argue about that. Robert Brinkerhoff, in Systems Thinking in Human Resource Development, argues that valuable initiatives produce an observable change in someone’s way of working. This principle is a great way to start a conversation on the value of stories or to unblock a sticky situation. In essence, translating Brinkerhoff’s idea to software means that it’s not enough to describe just someone’s behaviour, but we should aim to describe a change in that behaviour instead. This trick is particularly useful with user stories that have an overly generic value statement, or where the value statement is missing.
I recently worked with a team that struggled to describe acceptance criteria for a user story that was mostly about splitting a background process into two. The story was perceived to be of value because the business stakeholders asked for it. It was a strange situation, because the implication of the story is purely technical - a division of a background task. The success criteria was deceivingly simple - check that we have two jobs instead of one - so the team was worried that there is more to this than meets the eye.
The value statement was “being able to import contacts”. The problem was that the users were able to import contacts already, and they will still be able to import contacts after the story is done - there was no real success criteria. We tried to capture the value not just as a behaviour, but as a change in that behaviour, and the discussion suddenly took a much more productive turn.
Some people argued that splitting the background process will allow users to import contacts faster, but the total time for a split task would be the same. So either the solution was wrong, or the assumed value was incorrect. Digging deeper in what would be different after the story is delivered, we discovered that users were not able to import large contact files easily. Imported data was going directly into the database, where it got processed in several steps synchronously. For large files, this process took longer than the allowed time for a HTTP request, so the users would see an error on the screen. They would have to re-upload a file and wait to see if it will be processed.
We finally identified the change as “being able to upload larger sets of contacts faster”, and this opened a discussion on several potential solutions. One was to just store the uploaded file on the server and complete the HTTP request, letting the user go and do other things, while the same job as before picks up the file in the background and processes it. It was a better solution than the original request because it did not depend on the speed of the background process, and it also was easier and faster to implement.
In addition, understanding the expected change in behaviour of business users allowed the team to set a good acceptance criteria for the user story. They could test that a large file upload completes within the HTTP request timeout limit, instead of just checking for the number of background tasks.
Key benefits
Capturing a behaviour change makes a story measurable from a business perspective, and this always opens up a good discussion. For example, once we know that a change is about uploading larger groups faster, two questions immediately pop up: how much larger, and how much faster? The right solution completely depends on these two factors. Are we talking about megabytes or gigabytes? Are we talking about speeding something up by a small percentage, or by an order of magnitude?
This will help to determine if the proposed solution is appropriate, inadequate or over the top. Describing the change often sets the context which allows a delivery teams to propose better solutions.
Describing expected changes also allows teams to measure if a story succeeded from a business perspective once it is delivered. Even if the story passes all technical and functional tests, but fails to produce the expected behaviour change, it is not complete. This might lead the business sponsors to suggest more changes and different stories. The opposite is also true - if there are several stories aimed at the same behaviour change but the first one achieves more than planned, then the other stories can be thrown out of the plan - they are not needed any more.
A measurable behaviour change makes stories easier to split, because there is one more potential dimension to discuss. For example, if the behaviour change is “import contacts 20% faster”, offering a small subset of functionality that speeds up importing by 5% is still valuable.
How to make this work
Try to quantify expected changes - the good thing about a change is that is should be visible and measurable. Even if you do not end up measuring it at the end, capturing the expectation on how much something should change will help you discuss the proposed solutions.
If discrete values are difficult to set, aim for ranges. For example, instead of “10% faster”, ask about the minimum that would make a behaviour change valuable, and what would make it over the top. Then set the range somewhere in between.
Teams sometimes struggle to do this for new capabilities, or when replacing a legacy system. If the capability is not there yet, then “Start to” or “Stop doing” are valid behaviour changes. This will allow you to discuss what exactly “Start to” means. For example, a team I worked with had several weeks of work planned to enable traders to sell a new category of products, but it turned out that they can start to trade by logging purchase orders in Excel. The Excel solution did not deliver the final speed or capacity they needed, but traders started selling several months sooner than if they had to wait for the full big bang deployment to production, and this had immense value for the company.
