The Power of Negative User Stories

An Unorthodox Approach to Getting Important Work Noticed

“What’s that User Story about then?” asked the manager.

________

AS A Software Team

IF WE don't implement Infrastructure as Code

THEN THE CUSTOMER will face stability & reliability problems in production

________

“Ah, that’s something we were concerned about and wanted to bring to your attention,” I said.

“Go on,” said the manager.

“Yeah, so this piece of work is about us manually creating environments, which can lead to human error, inconsistencies, and missed elements. But if we took on this piece of work, we could avoid that,” I replied.

“Oh, I think I remember this. Dave mentioned it last quarter. How long do you think it could take?” the manager asked.

This is a very old conversation I had at a bank somewhere in London and was the start of something I liked to call “Negative User Stories.”

Typically, a User Story captures a requirement with the focus on the customer’s needs.

A Negative User Story is a twist on this concept!

It was born as an experiment and a reaction to important “under the bonnet” technical work not being prioritized by our boss.

I was working as a Scrum Master in a high-paced, aggressive environment, and there never seemed to be enough time to “do things properly,” as one of the developers used to say :)

When I say “do things properly,” I refer to several practices that happen under the bonnet but are related to modern software practices—things that make life easier for developers and also benefit the customer.

A negative user story

Is very straight forward and impactful!

It looks like this in your backlog:

AS A Software Team

IF WE don’t do X

THEN THE CUSTOMER impact will be Y

The persona part is cosmetic and really optional. Of course, the key part is identifying the negative customer impact of NOT doing this work!

Pick the part that hurts the most

Take the original example at the start of this post.

AS A Software Team

IF WE don't implement Infrastructure as Code

THEN THE CUSTOMER will face stability & reliability problems in production

Now look at all of the reasons as to why you should implement Infrastructure as Code:

If we don’t do it, we will see:

• Inconsistent Environments: Test environments will differ from production, leading to undetected issues that only appear after release.

• Slower Deployment: Manual setup is time-consuming, delaying our ability to release new features and fixes.

• Increased Errors: Human error in manual setups will cause more problems, impacting system stability and reliability.

• Customer Dissatisfaction: Unresolved issues in production will frustrate customers, damaging our reputation and losing trust.

Which of the above points would hurt the customer most?

How do we articulate it to get the attention and support of those in the business or product area?

Yes, implementing IaC ensures consistent, automated environments, reducing errors, speeding up deployments, etc. But what does it mean for the customer if we DON’T do it?

Let’s look at another example below.

(Remember, when you subscribe to our Substack, you are gifted a free seat in our mentoring group where we share the latest and greatest tips in the Agile space and help you think about the skills you need to increase to stay confident in your role or job hunt.)