User stories should be about behaviour changes

This is an excerpt from my upcoming book 50 Quick Ideas to Improve your User Stories. If you want to try this idea in practice, I’m participating in the Product Owner Survival Camp in Zurich in March and we’ll be playing around with hierarchical backlogs and behaviour changes then as well.

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. Rober 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.