Technical stories don’t make sense
As I learn more about stories and how they get written, I occasionally come across odd things that don’t make sense.
One of these is the technical story. Here’s an example:
As a developer,
I want an automated build
So that I can be sure my code works.
Of course, we’re resistant to letting developers have their own stories. So sometimes, instead, the technical story becomes:
As a business user,
I want developers to have an automated build
So that they can be sure their code works.
This doesn’t make sense to me either. Surely “working code” is part of another story, for any part of that story? Of course, the QAs are busy checking that code works! So why do we even need a build?
If there’s no benefit to the business, the chances are that a technical story isn’t really appropriate.
As a business user
I want the developers to refactor the UglyClass
So that... um...
Maybe not. In this situation, refactoring of UglyClass should happen when it enables some other piece of functionality to be delivered.
Feature injection helps us talk about the business benefit
There are some technical stories, though, which really do deliver something the business care about. You can find this out by asking, “Who cares if I don’t do this? Who cares if I don’t have an automated build? If I don’t write unit tests? If I don’t write acceptance tests?”
This is where the feature injection comes in. I’m flexing Chris Matts’s template a bit to do this; here’s how mine reads:
In order to <deliver some business benefit>
<these people>
will need <these features>.
Now we can start working out why it is that we write the automated build.
In order to minimize support costs due to poor code quality
The development team will need
To write scenarios and automate them.
In order to stop wasting money coding things that don't work in production
The development team will need
Automatic integration with a production-like environment.
In order to minimize the risk of our production environment falling over
The development team will need
Automated performance testing.
Users aren’t stakeholders
Interestingly, the people who care most about these things aren’t always the development team! The maintenance team care about support costs. The business stakeholders care about wasting money on code that doesn’t work. They also care about the production environment falling over.
We sometimes see this in normal stories too: that the user isn’t always the person who cares about the story.
As a user
I want to fill in a captcha box
so that... what? No! What a waste of my time!
Using “In order to…” we can turn this around:
In order to stop bots from spamming the site
Users will need
to fill in a captcha box.
Now it might be obvious that the beneficiary of this story is the person who has to moderate the site, or the commercial team whose adverts would become worthless in a morass of spam. But just in case it isn’t, we can capture both the stakeholder and the user:
In order to <deliver some business benefit>
As a <role> I want <some other role>
to <do something, or use or be restricted by some feature>.
In order to stop bots from spamming the site
As a member of the commercial team, I want users
to fill in a captcha box.
Feature injection helps us remove the implementation detail
So, going back to our technical stories:
In order to stop wasting money on code that doesn't work in production
As the budget owner, I want the development team
to integrate their code regularly with a production-like environment.
You might notice that when we word technical stories this way, the implementation detail – how the development team integrate their code – tends to fall away. All that’s important is that we do it; if automating that is the easiest way then we’ll do it that way.
(Interestingly, JBehave2 was developed with no automated builds. Running them manually was enough.)
Now we can talk about the business benefit of our stories
We can also see that there are three different things we can do with our new build, for three different stakeholders. Because we’re splitting up our technical stories appropriately, we can ask each of the stakeholders to help prioritise the stories, and to give us clear acceptance criteria.
In order to minimize the risk of our production environment falling over
As the person in charge of advertising revenue, I want the development team
to be able to verify the performance figures.
Now you know who you need in the story workshop, too.
“So, I want 90% of pages to load within 1 second, and it should be able to cope with the Christmas sales.”
Of course, the language still isn’t quite perfect, so you can now have the conversations about the real business benefit (maximising advertising revenue and user experience, minimizing the risk of the brand being stigmatized by an embarrassing failure) and splitting up the stories (situation normal vs. peak time).
“But, you know what? We’re not going to be able to do this until after we’ve finished the first internal release and have some idea of what the real content’s going to look like and which agencies we’re going to use for the adverts. Can we delay it till then?”
No problem. Let’s work on that first release.
Liz Keogh, lunivore 
Ahh excellent. I have always been looking for a good template for technical stories.
This was really helpful. Thanks!
This looks good. Thanks for giving us another way to think about stories. Your captcha example explained it perfectly.
Why not keep the same template and just clarify the role and benfit?
As member of the commercial team
I want users to fill in a captcha box
So that bots will be stopped/hindered from spamming the site.
I can’t believe there isn’t a reply to this excellent question!
Furthermore, why not just use the “new template” for every story? It is just the same meaning reworded.
Hi Al,
A couple of business stakeholders on one of the projects I was on used to refer to stories as “begging letters for functionality”. That’s because they would make their stories, come to the BA and hope that it somehow fitted into the vision that the analysts had for making money.
By putting the vision first, it helps people realise that they can’t – and shouldn’t – even start writing a story, unless it’s needed to contribute to the vision.
In order to keep me from getting bored looking after the kids when everyone else is partying
I need lots of interesting posts to keep me awake to the new year.
Loved it. More please.
In order to not get bored to death by writing the same general boilerplate text on hundreds very similar looking rather small stories, as a writer of user stories, I want a shorter template;
In order to not glaze over with boredom when reading hundreds of very similar rather small stories, and miss the point of the message in all the verbiage, as a reader of user stories, I want the writers of the user stories to use a shorter template.
I’m just about to try out this technique on a project…I’ll let you know how it goes! Fingers x-ed
This is a great way to capture the non functional requirements as well. I am going to use this for a project.
In order to provide integrity to the accounts created in the system,
As a member of the commercial team, I want users
to fill in a captcha box.
Pingback: Using Cucumber to Integrate Distributed Systems and Test Messaging • Blog Archive • Ben Mabey
Pingback: DevOps and the Iteration Showcase | Evan Bottcher
Sounds like flowery language and a forced template to justify low value stories for the craftsmanship crowd.
https://lizkeogh.com/2011/01/14/why-i-didnt-sign-the-software-craftsmanship-manifesto/ – I’m not exactly one of the craftsmanship crowd.
This is only one of the blogs and articles I’ve written on Feature Injection. Please feel free to explore the others. I also recommend Chris Matts’ work.
Pingback: Ubiquitous Language – a Choice of words « Unifying the SDLC
Pingback: Five Blogs – 22 October 2012 « 5blogs
Pingback: Gefunden: Feature Injection und wie man technische User Stories behandelt « MeinAuto Dev Blog
Nice approach, this could be a trap however.
Let’s imagine that I’m a kind of product owner and, for example, I have story such as this
“In order to minimize the risk of our production environment falling over
As the person in charge of advertising revenue, I want the development team
to be able to verify the performance figures.”
in my lovely backlog. Actually, it sounds as “In order to get as I command to “. But nevermind.
Well, the first question that comes to my mind is “does ability to verify performance figures really minimizes the risk”? I fear no, there are other factors like actually defects, environment stability (OS, disk, memory) etc. That makes this story non-integral, i.e. when the story is done I still doubt about the risk.
The second question is how to actually prioritize that? Users, oh sorry stakeholders, say, for example, that they want 1 ms when page loads, and 2 ms when I do Create/Update operation. This is value for them, not the fact that the developers team can monitor the performance. How to compare tech story with user one ? By ROI ? If I continue to think about this I would consider this story as a *waste* rather than a *value* (in terms of Lean) as it does not bring value to my customer. Does someone really wants doing the *waste* ? I hope not.
The last thing, how do I actually check if it is done? and the development team looks on these figures after the story is done?
-=X=-, there are two types of stakeholders – the championing stakeholder who has the initial vision and provides the money or fights to get it, and people whose goals need to be met in order to go live. The first is the only true product owner. Anyone else pretending to own the product is just a proxy.
When you do this, you have an MVP – a minimum viable product. You need to do *all* of it, in order to go live. If you don’t, it isn’t part of the MVP.
There are always aspects of a project that a team has never done before. Those are the riskiest bits. When you have the MVP, you can prioritise by risk and do those pieces first.
This means that if the team has never successfully delivered defect-free code before, or has never managed to hit the performance targets before, those might be the risky things to address first.
If the business aren’t sure that their figures are enough – if they haven’t tried this before and need to learn – then I wouldn’t be surprised if they wanted monitoring, as it helps *their* risk. I imagine you could probably go live without it to start with, though, and make it its own MVP later.
Also see this answer on PM StackExchange for why many technical stories provide options, so ROI is difficult to calculate on them. ROI shouldn’t be the only measure of value IMO. http://pm.stackexchange.com/a/7958/790
well put Liz, you should write up these ideas for agile record.com
Pingback: Originate Guides - Storywriting Best Practices - Originate | Concept-to-launch Acceleration Partner for Digital Products & Experiences
Than you!