Read this on medium.com via ideas.riverglide.com.

Imagine you’d never seen an orange or an apple before. Then, imagine you read a few articles showing an image of a shiny, red fruit, saying – “This is an orange, it will help you with your vitamin C deficiency”. It’s a similar shape to the foods you’ve eaten for other vitamin deficiencies so still fits your model. You proceed to eat lots of this red, shiny, crunchy, refreshing fruit and you teach your colleagues the same. Now they’re eating “oranges”…

“You keep using that word, I do not think it means what you think it means.”

After some time, your vitamin C deficiency still hasn’t improved. So everyone says “down with oranges, they don’t work”—including the some of the authors who’s articles you’d read. The problem was that you were eating apples, not oranges. But it’s too late, you, your colleagues, some authors of the articles you read—now have a disdain for anything labelled ‘oranges’.

This sounds ridiculous, but only because you know the difference between oranges and apples. Yet, it reflects the same kind of wide-spread misconception that has fuelled the growing disdain I’ve seen towards the Connextra Template—As a…I want to…So that…

Summary (TL;DR):

• Some believe User Stories are analogous to product features & that they should state business benefit – this is a fundamental misunderstanding;
• User Stories are about what the user will be able to do/achieve (not actions or features they’ll do it with);
• The Connextra template (As a / I want to / So that) helps us start valuable conversations about: who the user is, what they want to do and why;
• Some tried to ‘improve’ the Connextra template to capture features and business benefit (software requirements). These ‘improvements’ spread far and wide, propagating the ‘feature’ misconception of user stories;
• It’s not too late to make the paradigm shift away from writing ‘software requirements’ to truly understand user stories as ‘the story the user wants to be able to tell’;
• Truly understand the User Story paradigm and you realise that the Connextra template is as useful as ever.

The root of the misconceptions

Think of a User Story as a short-story that a user will be able to tell about what they want to do and why they want to do it. It’s not the feature the product will have or the actions they’ll perform, it’s what the user will be able to do – as in achieve. One story may actually mean subtle or significant changes to multiple features, involving several actions.

“Stories aren’t a different way to write requirements, they’re a different way to work”  -Jeff Patton

User stories are a paradigm shift, a different way of working. Jeff Patton explains this superbly in slides 1-50 of his User Story Mapping slides (I highly recommend you flip through them). Jeff highlights that “Stories aren’t a different way to write requirements, they’re a different way to work”.

 
The misunderstanding that User Stories are just a different way to write old-style software requirements has contributed to continuous deterioration in how the Connextra template is communicated across the industry—changing User Stories into product features (or user action within a feature). Product features and actions within them generally describe the product (not the problem)… again, like old-school requirements.

“A further problem with requirements lists is that the items on the lists describe the behavior of the software, not the behavior or goals of the user” –Mike Cohn, User Stories Applied (2004) Addison Wesley

Unfortunately, the problem wasn’t with the Connextra template, it was with widespread misinterpretation of it. This misinterpretation propagated so far and wide, that many teams now experience the problems caused by slicing work into product features (problems that User Stories are designed to solve). And now people are saying—“User Stories are broken!” and “the Connextra Story Template doesn’t work”. Clearly, comparing apples and oranges, much like in the opening story.

How did this happen?

The Connextra template highlights the who, the what and the why from the user’s perspective:

As a <someone>
I want to <do something>
So that <some result or benefit>

This helps us start the right conversation; exploring the short story a user could tell about something they’ll be able to do – hence the term ‘User Story’. The “As a…” helps us start empathising with the user. The “I want to…” gets us thinking about what they want to do (not how). The “So that…” get us closer to their motivation – why they’d want to do this.

Unfortunately, many people mistook User Stories to be just a different way to write requirements—which they’d always expressed as features & functionality. In their efforts to help colleagues and peers understand user stories in the same way, several people began sharing this template:

As a [role]
I want [feature]
So that [benefit]

Many teams found that whole features were too big to implement in a short enough window, so we also saw a variation on this where the interactions within the feature were described:

As a [role]
I want to [action]
So that [outcome]

Others sticking with the larger feature model, asked about ‘benefit’ part – what’s that for? Is it the benefit to the user? If it’s about the user, then where do we ‘document’ the business benefit? The question of ‘value’ and ‘business benefit’ was seen to be missing so we started to see:

As a [role]
I want [feature]
So that [business benefit]

People didn’t always know what the specific business benefit of a feature was so they started writing “As a… I want ” and left the “So that…” part out. So, a different format was put forward to encourage thinking about the business benefit and we ended up with a catch-all for feature or action—“functionality”—plus the business benefit as the opener (which became a confusion between what the business wanted and what the user wanted):

In order to <achieve some value>
as a <type of user>
I want <some functionality>

Whether it was the intent or not, I believe that these variations made it easier for teams to think they were working with User Stories when in fact they were simply capturing product-features and business-benefits like old-style software “requirements” – only dressed in a User Story like template.

The opportunity

User stories are about the user – hence the name. It’s a way of working, not a way of writing requirements. This is an area we all need to get better at explaining.

What we write on the User Story card (or electronic equivalent) using the original Connextra template helps us start the right conversation about users’ needs, slicing by value to the user. Starting the right conversation to slice by business value is a different problem.

The original Connextra template works just fine for User Stories that tell a story about the user. The template wasn’t trying to fix the mindset of slicing-by-feature. Books like User Stories Applied were there for that. The misconceptions began when people assimilated User Stories through their feature-biased filters and tried to ‘fix’ it – rather than question their own understanding.

This left many teams with “features dressed as stories” caused by a fundamental, yet common, misunderstanding. Who knows, I may have once shared in that misunderstanding myself. Now, we have an opportunity to change this by learning more truths about User Stories so that we can all benefit from increased agility.

Have you been working with features dressed as stories? If so, and you want that to change, here’s a place to start.

 

Antony/Andy would know how to make what I’m doing better/easier right now, if only they were here!

Maybe all you really need is 30 minutes to an hour pairing or just talking, not a whole day of our time. Maybe all you need is a few emails back and forth between us. Rest assured, we’re here and we’re happy to help, on anything including:

• For product and technology teams:
  • Thinner slicing of your Minimal Viable Products (MVP)
  • Effective user stories, Feature Injection & agile business analysis
  • Effective Cucumber scenarios
  • Communicative, narrative code
• For coaches, managers and leaders:
  • Values & building a culture of innovation
  • Enabling more adaptive teams
  • Challenges of culture and process change
  • Facilitating effective workshops: story-sizing/planning/retrospectives

All sessions are strictly confidential and we’re more than happy to sign a mutual non-disclosure agreement if required. If you aren’t sure if either of us can help, why not get in touch and let’s see. If we can’t, it won’t cost you anything…

Individuals: Pay what you think it was worth

Maybe you need to talk about a challenge you’re facing with your team, colleague or management. Perhaps you have some nightmarish Cucumber scenarios that are making your head hurt. Perhaps you just need someone independent to bounce ideas off.

We’ll have a conversation on Skype, Google Hangouts, Facetime or just on the phone. At the end of the time, all you do is:

• Tell us what you thought it was worth and
• Pay only what you are comfortable paying

Money is relative to both your personal income and your responsibilities. You know what they are and we trust you to make a fair exchange of value. All we ask, when you pay whatever amount you’re comfortable with, is to tell us what you thought the session was worth.

You may work in a company that trusts & values your judgement, allowing you to expense personal development activities. This model equally applies, but when that isn’t an option…

Companies: Pay what you think it will be worth

Many large, established companies find it hard to work in the above way. You may not feel you have the freedom to work in the above way (in which case we really should talk). Your manager may want to sign it off and your finance team may want to have a purchase order in place for a fixed amount before you talk to us. So, if you want let’s talk a bit about the challenge and what a new way forward in addressing that challenge is worth. We’ll agree a price and we’ll go from there.

After a chat, you might find that you have a lot more freedom than you think and we can help you make things easier. For more information, get in touch with an email or a call to +44 845 056 9606. We’re happy to help.

A user story is a “short descriptions of functionality–told from the perspective of a user–that are valuable to either a user of the software or the customer of the software”[1]. You may first encounter stories in this form:

As a microblogger,
I want to find out as soon as others mention me,
So that I can choose to respond while topics are current.

One common misunderstanding of user stories might result in the above example looking more like this…

As a microblogger,
I want a notifications screen showing my mentions,
So that I can find out as soon as others interact with me.

The problem here is thinking of user stories in terms of what the user will have, rather than what they’ll be able to do. This can cause avoidable dependencies that limit your flexibility, reduce your speed to market and limit your ability to change direction based on market feedback.

These dependencies can be dramatically reduced if our user stories steer the conversation towards what the user will be able to do. Let’s explore why…

What the user will have (features)…
Let’s imagine we envision a house (which will be made of lego in this exercise). What stories would you write for your lego house? Here are some of the typical stories people write:

• As a cook,
  I want a kitchen,
  so that I can prepare food.
• As a parent,
  I want a master bedroom,
  so that I can sleep comfortably with my partner.
• As a car-owner,
  I want a garage,
  so that I can park my car off the street.

Have a think about what’s involved in delivering these stories with a lego house, building our final vision of the kitchen, the bedroom, the garage. If our vision is to have the master bedroom on the top floor, then we can’t have a place to sleep until we’ve built the ground floor. To build our garage ‘iteratively’ we will focus on building the walls first, then put the roof on. Essentially, the architecture drives the order of implementation, not what is of greatest value to us.

The problem here is that these stories are encouraging us to fixate on specific solutions to each problem. Ideally, we want the story to be about what the user will be able to do (i.e. sleep comfortably together), not what they’ll have (a bedroom).

In these examples, as is often the case, the problem we’re trying to solve is there, just in the ‘so that’ part. Getting everyone to share in an understanding of the problem(s) we want solved helps us prioritise based on business value…

What the user will be able to do (capabilities)…
Now, imagine if we had stories like this:

• As a cook,
  I want to prepare hot food for the family,
  so that we can safely enjoy various fresh foods.
• As a parent,
  I want to sleep comfortably with my partner,
  so that we can keep each other warm.
• As a car-owner,
  I want to park somewhere safe,
  so that I can keep my insurance premiums low.

Have a think about the different ways we could initially solve these problems (from camping cookers, a mattress on the floor and a driveway to park the car). We can meet all of these needs rapidly without having to achieve the final vision but make it possible to layer on more and more refinement to each one evolving to the solution and enabling us to discover the solution we really need.

when what we want is “a thing” then what we are describing is not a user story – it is a feature.

Features (“I want a…”) vs. Capabilities (“I want to…”) 

Relatively recently, while running my user stories course (with Lego) to delegates at a well known company, one delegate pointed out a difference between the ‘template’ for the two story styles above. They observed that in the case of stories that are really “Features” the format tended to be “I want a…” whereas for stories that were “Capabilities” the format tended to be “I want to…”. Some found ways around this by saying “I want to have a…”.

Interestingly, the original ‘Conextra Template‘ indeed followed “I want to…” and all of Mike Cohn’s examples in his book “User Stories Applied” are indeed capabilities (although sometimes in his explanations he does refer to stories as describing a feature, his examples are generally capabilities).

In short, when what we want is “a thing” then what we are describing is not a user story – it is a feature.

(This short section was added on: 22nd May 2015)

Flexibility & Adaptability…

Each of these stories may be broken down even further. Let’s look at the garage and all the needs a garage might meet

• As a car-owner,
  I want to park my car off the street,
  so that I can reduce my insurance premiums
• As a car-owner,
  I want to shelter my car from the rain,
  so that I don’t have to wash it as often.
• As a car-owner,
  I want to hide my car from onlookers,
  so that opportunists don’t think of stealing or vandalising it.
• As a car-owner,
  I want to hinder thieves from driving my car away,
  so that I get the lowest insurance premiums.
• As a car-owner,
  I want to securely store my tools near the car,
  so that it’s easier to do basic maintenance.
• …and so on.

Now think of the different ways we could meet those needs with our lego house?

Most of these stories are largely independent of each other and can be delivered in almost any order. This allows us to prioritise the stories based on value rather than the architecture of the final vision.

We’ll realise our first piece of value very quickly and continuously gain more and more value until eventually we’ll have a whole garage (if that’s what we really need). If this was something that makes us money, it would mean we’d be generating revenue sooner. Revenue would grow continuously as we continuously grow our product.

It also means we can change direction at any time, for example if we were to start getting feedback taking the garage more in the direction of a workshop with space for a car rather than just a simple garage.

In the real world
I recently helped a client interview people who had from three to five years “experience” with user stories. During the interview I pulled out some index cards and pens. I described a simple product (which was surprisingly similar to early incarnations of Twitter) and invited them to help us write some user stories for our backlog.

What each of them wrote was, essentially, a functional specification, split like use-cases into several cards, except using the above “As a… I want… So that…” template. They explained each story in terms of the screens in the user-journey such as Registration, Login, View Profile, Follow Other Users, Post a Status Update, View Status-Updates and so on. The real issue here isn’t in the name of the story, it’s in what the stories represented in their minds…

I asked them to help us prioritise them based on value. “Registration is most valuable because without it we can’t do anything else”–one interviewee explained. This means that it would not be possible to obtain any feedback about the main value proposition of the product until a number of user stories are complete. Each candidate explained the stories as dependent steps in a journey that, essentially, had to be built in the same sequence as the journey [4].

The main value proposition is sharing updates with people and seeing what others are saying. A simple screen-name (like in a chat room) will do  initially. Registration and login are largely about hindering others from pretending to be me. Could there be simpler ways of achieving this at first?

Like I said, I’m not suggesting that any of the story titles that each candidate came up with are invalid, just that they thought of them in terms of the expected solution (what the user will have), not understanding the real problem (what valuable thing the user will be able to do).

In Closing…
With tractable mediums like lego or code (with the right engineering practices around it), we are able to evolve our product to meet each user-need in turn.  This is facilitated by thinking of our user stories in terms of the outcome (e.g. shelter from the rain) rather than one possible output (e.g. a roof and four pillars). Ultimately, this way of thinking is one of the key upstream enablers to realising value early & often and brings more opportunity to rapidly adapt to feedback by dramatically reducing dependencies.
——————————-
Experience this for yourself: If you would like me to run this as a hands-on workshop with your team(s), let me know. We’ll explore how user stories work in practice, not only by writing the stories, but understanding the conversation and means of confirmation [3] that complete the practice of user-stories. I can also wrap this in a simulation of Scrum and/or Kanban so that teams can experience how user stories work in practice. I make it accessible to all team members using lego as a metaphor for software, demonstrating the principles described above. We then explore how to apply this to your products, writing some stories or reviewing and refining your existing stories to take what we learn into the real world.

Acknowledgements:
The Lego House exercise that I run has been created by combining my experience with a number of other exercises, including the “XP Lego Game” and Rachel Davies‘ Household Stories exercise.

Footnotes:

[1] “Advantages of User Stories for Requirements” by Mike Cohn (See also his book, “User Stories Applied”)
[2] Typical user story format: http://guide.agilealliance.org/guide/rolefeature.html
[3] There is a lot more to user stories than this three line statement. The simplest explanation is that this is just the ‘Card’ in the three C’s of User Stories: http://guide.agilealliance.org/guide/threecs.html
[4] A key characteristic of user stories is there are few dependencies, if any, between them and each is valuable. This is explained by the mnemonic INVEST: http://guide.agilealliance.org/guide/invest.html

To me, modern (agile) software development feels more like pottery. But, instead of ‘throwing clay’ we throw our consciousness, in the form of electrons flowing over silicon, onto a spinning wheel of user-story implementation cycles.

We evolve our understanding of what our customer wants with each conversation. We reflect that understanding by evolving the product’s shape as we touch the outer surface with each new automated acceptance test (or example scenario). We evolve its structure as we touch the inner surface with each new unit test (or unit specification). We keep it supple as we moisten it with each refactoring. Our customer looks on, gives us feedback and we start the next revolution of the software development wheel. Never letting the product dry and harden; keeping it flexible, malleable, soft(ware).

There is nothing that feels like construction here. I never feel like I’m “building” something. Much more like I’m evolving my understanding, evolving the product, evolving my understanding again and so on.

For these reasons l am not comfortable with referring to this process as “building”. I’m also not comfortable calling it “throwing” (as in pottery).

I am very comfortable calling it “development”. I use the word “develop” in terms of its literal meaning:

“to bring into being or activity; generate; evolve.”
–dictionary.com

From the first thought of a new idea, through each conversation along the way, to each revolution of the software development wheel, I develop products.

I don’t “build”.

I create. I make. I shape. I evolve.

—————————
Footnote: I’m not aware of anyone drawing this analogy before. If you have heard or read someone explain it in this way before now, please let me know.

Such confusion results in questions like the one asked of Rachel Davies recently, i.e. “When to write story tests” (sometimes also known as “Acceptance Tests” or in BDD parlance “Scenarios”).

In her answer, Rachel highlighted that:

“…acceptance criteria and example scenarios are a bit like the chicken and the egg – it’s not always clear which comes first so iterate!”

In that article, Rachel distinguishes between acceptance criteria and example scenarios by reference to Liz Keogh’s blog post on the subject of “Acceptance Criteria vs. Scenarios”:

“where she explains that acceptance criteria are general rules covering system behaviour from which executable examples (Scenarios) can be derived“

Seeing the acceptance criteria as rules and the scenarios as something else, is one way of looking at it. There’s another way too…

Instead of Acceptance Criteria that are rules and Acceptance Tests that are scenarios… I often find it useful to arrive at Acceptance Criteria that are scenarios, of which the Acceptance Tests are just a more detailed expression.

I.e. Scenario-Oriented Acceptance Criteria.

Expressing the Intent of the Story

Many teams I encounter, especially newer ones, place higher importance on the things we label “acceptance criteria” than on the things we label “acceptance tests” or “scenarios”.

By this I mean that, such a team might ultimately determine whether the intent of the story was fulfilled by evaluating the product against these rules-oriented criteria. Worse still, I’ve observed some teams also have:

• Overheads of checking that these rule-based criteria are fulfilled as well as the scenario-oriented acceptance tests
• Teams working in silos where BAs take sole responsibility of criteria and testers take sole responsibility for scenarios
• A desire to have traceability from the acceptance tests back to the acceptance criteria
• Rules expressed as rules in two places – the criteria and the code
• Criteria treated as the specification, rather than using specification by example

If we take the approach of not distinguishing between acceptance criteria and acceptance tests (i.e. see the acceptance tests as the acceptance criteria) then we can encourage teams away from these kinds of problems.

I’m not saying it solves the problem – it’s just easier, in my experience, to move the team towards collaboratively arriving at a shared understanding of the intent of the story this way.

To do this, we need to iteratively evolve our acceptance criteria from rules-oriented to scenario-oriented criteria.

Acceptance Criteria: from rules-oriented to scenario-oriented:

Let’s say we had this user story:

As a snapshot photographer

I want some photo albums to be private

So that I have a backup of my personal photos online

And let’s say the product owner first expresses the Acceptance Criteria as rules:

• Must have a way to set the privacy of photo albums
• Private albums must be visible to me
• Private albums must not be visible to others

We might discuss those to identify scenarios (as vertical slices through the above criteria):

• Create new private album
• Make public album private
• Make private album public

Here, many teams would retain both acceptance criteria and scenarios. That’s ok but I’d only do that if we collectively understood that the information from these two will come together in the acceptance tests… And that whatever we agree in those acceptance tests supersede the previously discussed criteria.

This understanding tends to occur in highly collaborative teams. In newer teams, where disciplines (Business Analysts, Testers, Developers) are working more independently this tends to be harder to achieve.

In those situations (and often even in highly collaborative teams) I’d continue the discussion to iterate over the rules-oriented criteria to arrive at scenario-oriented criteria, carrying over any information captured in the rules, discarding the original rules-based criteria as we go. This might leave me with the following scenarios:

• Create new private album (visible to me, not to others)
• Make public album private (visible to me, not to others)
• Make private album public (visible to me, & others)

Which, with a subtle change to the wording, become the acceptance criteria. I.e. the story is complete when we:

• Can create new private album (visible to me, not to others)
• Can make public album private (visible to me, not to others)
• Can make private album public (visible to me, & others)

Once the story is ‘in-play’ (e.g. during a time-box/iteration/sprint) I’d elaborate these one at a time, implementing just enough to get each one passing as I go. By doing this we might arrive at:

Scenario: Can Create new private album
When I create a new private album called "Weekend in Brighton"
Then I should be able to see the album
And others should not be able to see it

Scenario: Can Make public album private
Given there is a public album called "Friday Night"
When I make that album private
Then I should be able to see the album
And others should not be able to see it

Scenario: Can Make private album public
Given there is a private album called "Friday Night"
When I make that album public
Then I should be able to see the album
And others should be able to see it

By being an elaboration of the scenario-oriented acceptance criteria there’s no implied need to also check the implementation against the original ‘rules-oriented’ criteria.

Agreeing that this is how we’ll work, it encourages more collaborative working – at least between the Business Analysts and Testers.

These new scenario-based criteria become the only means of determining whether the intent of the story has been fulfilled, avoiding much of the confusion that can occur when we have rules-oriented acceptance criteria as well as separate acceptance test scenarios.

In short, more often than not, I find these things much easier when the criteria and the scenarios are essentially one and the same.

Why not  give it a try?

In a previous post I talked about Critical Mass of software. I showed how an ever-increasing cost of change resulted in it becoming more economical to completely rewrite the system than to enhance and maintain the original.

I explained how this could be avoided by using practices that sustain a consistent and flat cost of change. I also mentioned that you could defer reaching critical mass. Some teams find it difficult to get the time to do this because “the business” always has “more important” or “higher-value” things on their backlog.

What are the implications of reaching critical mass? Well, depending on what the software does and whether the rewritten version still has to do all of those things, it could cost millions… or more.

Presented with the situation that the product could reach critical mass within a year – costing millions to replace – do you think “the business” would start to think it is worth investing in reducing the cost of change? Obviously, I would advise teams to avoid this situation in the first place:

The reality for many teams I’ve encountered is that they don’t feel empowered to push back on the business’ demands for that next feature in half the time it takes to do it properly. If we could present back the impact of that choice as shortening the time to Critical Mass and bringing about costs to replace the software far in excess of the value gained by delivering that feature a month early then perhaps the business would be better informed.

A big visible chart on the wall, showing the estimated point at which Critical Mass was reached could play a big role in getting the business more interested in sustainable change, or at least inspire a conversation on the subject.

Convincing “the business” to invest in some remedial refactoring or allowing three times as long for each feature to facilitate enough remedial refactoring for each new feature and refactoring-as-we-go for the new feature might be easier if we could represent this idea visually:

The problem with this idea is how do we credibly determine when Critical Mass is going to be reached? Many experienced practitioners could probably reasonably accurately estimate when that was going to happen purely on gut feel but this would be torn to pieces by many product managers. I’ve not solved this problem yet because doing this would require a mathematical model, determined by empirical data.

Perhaps someone will take inspiration from the ideas in these blog posts and find a solution. Perhaps someone has already done this or maybe this is an idea for a future PhD I might undertake? Maybe someone else will take inspiration from this article and undertake that work before I do. If so, they’re welcome to (with due attribution where applicable of course

I think it is possible, however, to come up with a simple model based on the average complexity per unit of value (assuming that the team is using value and complexity). Trending this and keeping an estimate of a complete re-write up to date might allow the simple charts above to be maintained along side release-level burn-down charts.

These ideas are still in their infancy for me. Has this problem been solved already? If not, I encourage others to explore my hypothesis and help take it from just an interesting idea to something more useful.

A while back I tweeted about critical mass of software:

Critical Mass of Code – past which the changeability of the code is infeasible, requiring that it be completely rewritten.

An elaboration of this might be:

Critical Mass of Software: the state of a software system when the cost of changing it (enhancement or correcting defects) is less economical than re-writing it.

This graph illustrates a hypothetical project where the cost of change increases over time (the shape of which reminds me of a thresher shark):

Note:The cost of a rewrite gradually grows at first to account for the delay between starting the re-write and achieving the same amount of functionality in the original version of the software at the same point in time. The gap between the cost-of-change and the cost-of-rewrite begins to decrease as the time it takes to implement each feature of comparable benefit in the original version grows.

It was just one of those thoughts that popped into my head. I soon discovered that critical mass of software is not a new idea.

One opportunity that I feel organisations miss out on is that this can be used as a financial justification for repaying technical debt, thus preventing or delaying the point at which software reaches its Critical Mass, or avoiding it altogether.

Maintaining quality combined with practices that keep the effort involved in completing each feature from growing over time can defer critical mass indefinitely:

Note: The cost of a rewrite is slightly less at first assuming that we are doing a little extra work to ensure that we get the infrastructure we need up and running to support sustainable change (e.g. continuous integration etc.)

This flat cost of change curve is one of the motivations of many agile practices and software craftsmanship techniques, such as continuous integration, test-driven-development, behaviour driven development and the continuous refactoring inherent in the latter two. A flat cost-of-change trend is good for the business, as they have more predictable expenditure.

The behaviour I’ve noticed with some teams is to knowingly accrue technical debt to shorten time to a near-future delivery in order to capitalise on an opportunity and then pay it back soon after:

This certainly defers reaching critical mass but it doesn’t prevent it.

Unfortunately, I see more teams taking on technical debt and not repaying it (for various reasons, often blamed on “the business” putting pressure on delivery dates).

If we had a way of estimating the point at which we’d reach critical mass, we’d be able to compare the benefit of repaying technical debt now in order to avoid or delay the cost of a rewrite… or even better, demonstrate the value of achieving a flatter cost of change.

I’m not sure that we have the data or the means of predicting it, but perhaps these illustrations of a hypothetical scenario will help you explain why sustaining constant quality, automating repeatable tests (or checking as some prefer to call it) wherever technically possible and, on those occasions when we do need to make a conscious choice to compromise quality to capitalise on an opportunity, that the debt is repaid soon after.

One company I know reached this point a couple of years ago and embarked on a department wide transformation to grow their skills in agile methods so that they not only re-wrote the software but could also avoid ever reaching critical mass again. A bold move, but one that paid off within a year. Even for them, they’ll need to avoid complacency as time goes on and not forget the lessons of the past. Let’s hope they do.

“Few would think that Special Forces tactics bear any relation to software project teams. But Antony Marcano draws a surprising parallel between the dynamics of modern Special Forces “room-clearing” methods and the dynamics of modern software development teams.”

My thinking has moved on slightly since then. Recently, several people have expressed an interest in the article.

So, here is an updated version, based on my more recent thinking and with some additional detail that had to be omitted from the original due to word-count restrictions of publishing in printed form…

Please note – The comparison with military and police armed forces is purely metaphorical and specific to the message I hope emerges about roles and titles.

Lessons Learned in Close Quarters Battle

I’m at the door, heart pounding so loud I’m sure everyone can hear it. Four silhouettes are flat to the wall. I’m point man, stuck to the edge of the door we’re about to breach. The team lead whispers through a covert radio mike,  “Alpha 1 in position.” Silence… tense anticipation… then, after a thirty-second eternity, my earpiece crackles as control responds, “Standby… Standby… Strike! Strike! Strike!”

The method of entry (MOE) man, on the opposite edge of the door frame, kicks in the door; behind me, the team lead throws in a stun grenade. BANG! As point man, I enter immediately—followed by number two—and five action-packed seconds and three targets later, we’re able to call out “ROOM CLEAR!”

Instantly, we move to the next room. The MOE man is nearest to it, immediately becomes point-man. The man on rear cover follows taking up the MOE position, becoming the MOE man. Meanwhile, the original number two and I are exiting the room.

I’m the first out and, seeing that the number two position on the next door is yet to be filled, I fall in behind the point man, becoming team lead. I am now responsible for calling the next breach and for throwing in the next flash-bang. The former number-two drops in behind me to provide rear cover. Each of us instantly switches roles, and with a deafening bang, the next door is breached without hesitation.

This might sound like a scene from an action movie but, no, it was a close quarters battle (CQB) training session I attended with the rest of The Foundation:Special Operations Group—a top UK Airsoft team. Airsoft is a skirmishing sport similar to paintball but with more realistic looking equipment and no mess.

In this training session, run by a private security contractor, we were practicing the latest CQB techniques taught to police and military armed forces. In CQB situations, armed forces don’t have time to shuffle around to get team members into the position that an individual’s job title might dictate. Lives are at stake (or points in Airsoft). The team must be able to adapt instantly; there can be no waste in the process.

Fixed Roles are accompanied by Waste

Historically, CQB dynamic entry (room clearing) was, and still is in places, taught with fixed roles. Instead of each person reading the situation and falling into the position that maximises the flow of the team from room to room, each person had a fixed role.

Prior to practicing the dynamic role-switching, or ‘read system’ we also tried the fixed role position. This was noticeably slower. Instead of the team-members outside the room falling straight into the position on the next room, they had to wait for the number 1 & 2 (and sometimes number 3) to exit the first room and get into position covering the next door. Only then could the MOE specialist move to the door allowing the last team-member to move up to continue their role providing rear cover.

The extra time it takes waiting for each specialist to be in position can take 10-30 seconds longer per-room. This time adds up to several minutes of wasted time when you have a whole series of rooms to clear. This fixed-role system not only puts the same person at the greatest risk as point-man on each room, as was highlighted by a British Army CQB instructor I trained with last year, but reduces your flexibility or can even halt the operation—especially when one of your team-members is injured (or worse).

If everyone is a specialist, you need more people in those specialist roles to deal with the risk that one of them could be taken out at any time. We don’t have quite this concern in software teams, however, people do fall ill or need time off work for personal reasons.

We Still Need Experts

Indeed, there are experts within a dynamic team. For example, our MOE expert might tackle the especially tricky entries or advise the team on entry tactics before the game, but we all are capable to some degree in MOE. Each of us is capable of dynamically switching roles, quickly adapting to changing circumstances. This is a perfect example of a truly cross-functional team of generalising specialists [1].

Skills Demands are Constantly Changing

This dynamic role switching is almost the opposite of your typical software organisation where each person has a job title that fixes his role—business analyst, programmer, tester. These job titles make complete sense in phased-development approaches (e.g. waterfall) where the work is divided up as if it were a production line: Business analysts pass the outcome of business analysis to developers who pass the result of development on to testers and so on. These job titles make less sense when using agile approaches that integrate these activities so tightly that they are all but inseparable.

More significantly, however, the balance of skills needed during each iteration (or time-box) and even for each user-story fluctuates depending on the nature of the features being implemented. One change may involve more refactoring (changing internal and not external behaviour) and be largely protected by pre-existing automated tests. Another change may involve limited coding and much more exploratory testing. There are endless variations on how the emphasis on each skill-area will change as the work flows through our value-stream.

Like the Airsoft (or Special Forces) team going from one room to the next, software teams must seamlessly go from one story (or feature or business-value-increment) to the next. It’s simply too wasteful for progress to be halted while we wait for a fixed-role specialist to finish his previous task.

Everyone on the team must constantly adapt so that we continue to maintain a constant and efficient flow of value… Fulfilling our shared responsibility of frequently delivering working software.

History Repeating?

An increasing number of organisations seem to recognize this, creating a demand for multi-skilled people. Interestingly, however, history seems to be repeating itself!

Up to the mid 1990s, high- and low-level software design was performed by systems analysts and then coded by programmers. Perhaps due to the demands of rapid application development, the roles later combined and the multi-skilled analyst-programmer emerged. Subsequently, this became the norm and analyst-programmers were thereafter known only as “developers.”

Today the title of developer-tester (or tester-developer) is emerging in response to the flexibility demanded by agile teams—kind of an analyst-programmer-tester. As the uptake of agile methods grows, this demand is only going to rise! If history indeed repeats itself, the developer-tester may, too, become the norm—negating the need for the “tester” suffix that differentiates them. Yes, the “software tester” job title, one of the few remaining titles derived from phased-development methods of old, could suffer the same fate as Ye Olde Systems Analyst.

This wouldn’t mean that software testing as a discipline will disappear altogether—just that many of the testers and developers of today will need to leave their comfort zones to become the developers of tomorrow.

Acquire ‘Tags’ or Badges – not a Job Title

Fixed, specialised job titles alone could be part of the problem. Maybe we need to stop linking specific roles to job titles. So often at conferences people ask the audience, “put your hand up if you are… analysts… programmers… testers… designers…”

I notice that many people will only put their hand up when one of these is called. You may notice me put my hand up for each of these roles. I think of these labels more like tags than titles. I feel I can tag myself with all of these roles and switch between them (to varying degrees of competency) as the situation demands.

Maybe they’re not so much like tags as badges. In some forces and certainly in the cadets and even among scouts and brownies, as you demonstrate new skills, you are entitled to wear new badges.

The difficulty with fixed-role thinking is that for many, their very identity is attached to their job titles. The challenge becomes showing people why they would want to broaden their thinking. I’m not sure I have time to address that in this particular post.

Maximise (your) Value

I can tell you what’s in it for me, personally. The tasks most relevant to my job-title may not be relevant to the team’s current story or goals. By dynamically switching roles, I am able to do the task that is the most relevant and valuable to the team at that time, within the context of the project’s goals, rather than just the tasks of most relevance to my job title. I am then able to accelerate the speed at which the team can clear each story, as the CQB team clears each room.

I recognise that this isn’t always immediately practical. Some teams are very protective over access to source code… but this is a matter of trust. There are many ways you can earn this trust… It may be that you need to demonstrate your abilities to manage your own git, mercurial or subversion repository before you’ll be given access to the relevant project repositories. It may be that you can demonstrate that you are able to build an open-source code-base using similar technology on your own. You may simply need to be able to talk about the right things while asking another team-member with a different area of expertise for help – demonstrating that you’ve at least understood the basics. So, one of the things outside your job-title that may add value to the team might be learning how to do something that the team will soon need doing.

So, hold on to your job titles and stick to your job descriptions if you choose. Personally, I’ve chosen to develop my individuality, embrace new skills and acquire new ‘tags’ & badges—bringing to the team more value, flexibility, throughput and opportunity.

References: [1] Ambler, Scott. “Generalizing Specialists: Improving Your IT Career Skills.” Agile Modeling, 2006. www.agilemodeling.com/essays/generalizingSpecialists.htm

To find out more about Airsoft or to take your colleagues on a similar journey to this article, check out http://firefight.co.uk. Tell them that this article sent you their way… they know who I am and have already taken one of my client’s teams on a similar journey.

Feature Injection, an approach to Agile Business Analysis created by Chris Matts, is a much misunderstood thing –. It is a way of combining several techniques to understand just enough of a business problem to start expressing solutions to it. It provides specific techniques to incrementally and iteratively comprehend each of the following:

• The business value sought (the why)
• The problem domain (what specifically needs solving to deliver that value)
• The resulting roles, incentives and product capabilities (the solution)

Basically, it helps us to evolve everyone’s understanding of the business-need as we (by other means) also evolve the implementation of the product.

Now, before you say, “it’s nothing new”, Chris Matts will be the first to agree. He’s taken his experience of various techniques, combined several of them that often work, evolved it into an approach to agile business analysis and given it a name.

I wish I could explain all of this now, but we’ll have to save that for another day. This post is intended to try to explain the relationship between Feature Injection and User Stories.

I’ve seen several examples of user stories taking some inspiration from Feature Injection, however, I’m not sure any of them do Feature Injection enough justice.

A common story

One of the problems with how User Stories are often applied is that people focus on the role, the capability and then try to work out what the benefit is. This is quite natural, explained nicely by Udi Dahan:

Users ultimately dictate solutions to us, as a delta from the previous set of solutions we’ve delivered them. That’s just human psychology
– writer’s block when looking at a blank page, as compared to the ease with which we provide ‘constructive criticism’ on somebody else’s work

This is something that other aspects of Feature Injection actually help you to solve… but again, today I’m just focusing on user stories…

The tendency of people to dictate solutions, rather than the problem that needs solving, has lead some to emphasise that we should put the benefit of the story first. For example, let’s say a fictional printer manufacturer consistently entices 3% of everyone they e-mail, reminding them to check their ink-levels, to purchase print consumables. In this situation, some might illustrate taking a story like this…


As the PrintCo marketing manager
I want customers to register their e-mail addresses
So that we increase the sales of our print consumables

And changing it to this:


In order to increase the number of sales of our print consumables
As a marketing manager
I want customers to register their e-mail addresses

The intent behind this shuffling around is to get people to think about the problem in order of business value first, then the stakeholder then what the stakeholder thinks will deliver the value.

But, the story is talking about a stakeholder… In my experience, this doesn’t get the best value from the user story approach.

Stakeholder ‘stories’ or User Stories?

I’ve found that user stories are most useful when communicating to the team if they encourage a conversation around who the user is, what capability the user needs and why it’s important to the user (could that be why they are called “user stories”?). This helps us to understand what user experience they need and what capability will make that possible.

This template, brought to us by Rachel Davies and Tim McKinnon’s 2001 XP Day session “Tuning XP”, helps us with that:


As <some role>
I want <some capability>
So that <some benefit>

If we discuss this solely from the business stakeholder’s point of view, the team doesn’t get as much understanding from what is needed by the user or why the user will need this capability. If the capability summarises what the product will enable or do for user it’s a lot easier to see what needs to be changed in the product. The benefit should be the answer to “what’s in it for the user?” or “why would they want the product to do that?” (exploring the persona of the user is helpful in finding this out).

So, taking the earlier PrintCo example, an alternative way of writing the user story would be like this:


As a PrintCo Customer
I want to be prompted to share my e-mail address with PrintCo
So that I can avoid those times when I need to print something but the ink is empty

Ah… but now we’re back where we started – where’s the business value? How do we get people to think about the business value first and then identify the roles and capabilities?

Let’s start again

Ideally, we want the benefit of driving the features from the business value and the increased understanding of what we’re implementing by understanding the user in our conversations around a user story.

To get to the right place, we need to start again with our example. Imagine that, instead of the above, we’d taken a different approach.

Recall that the business value or goal was:

Increase PrintCo printer cartridge sales by increasing our customer mailing list

Then, we could consider what behaviour we want to encourage and for whom. For example, we want the Customer to share their e-mail address with us online.

So, what will encourage that behaviour… What’s in it for our users? Into our business value statement, we “inject” the beginnings of a capability (or feature) that will help us deliver the value:


In order that PrintCo printer cartridge sales go up by growing the mailing list:
As a PrintCo Customer
I want <something>
So that an e-mail reminder helps me to avoid those times when I need to print something but the ink is empty

Now we’re ready to talk about the special <something> that we don’t currently have that will give the user the benefit they want:


In order that PrintCo printer cartridge sales go up by growing the mailing list:
As a PrintCo Customer
I want to be prompted for my e-mail address
So that an e-mail reminder can help me avoid those times when I need to print something but the ink is empty

We also want the Customer Services Rep to be encouraged to ask customers for their e-mail address when dealing with customers over the phone. So, we inject some more features:

In order that PrintCo printer cartridge sales go up by growing the mailing list:
  As a PrintCo Customer
  I want to be prompted for my e-mail address
  So that an e-mail reminder can help me avoid those times when
    I need to print something but the ink is empty

  As a PrintCo Customer Services Rep
  I need <something>
  So that I increase the points I get for e-mail captures, improving my
    position on the high-scores display

  As a PrintCo Customer Services Rep
  I need <something>
  So that I can see that the points I earn for e-mail captures affect my
    position on the high-scores display

And now we want to know what that special something is going to be for our Customer Services Rep:

In order that PrintCo printer cartridge sales go up by growing the mailing list:
  As a PrintCo Customer
  I want to be prompted for my e-mail address
  So that an e-mail reminder can help me avoid those times when I need
    to print something but the ink is empty

  As a PrintCo Customer Services Rep
  I need to be prompted to ask for the customer’s e-mail address
  So that I increase the points I get for e-mail captures, improving my
    position on the high-scores display

  As a PrintCo Customer Services Rep
  I need e-mail captures shown as one of the columns on the high-scores display
  So that I can see that the points I earn for e-mail captures affect my
    position on the high-scores display

And, if it is important that you capture the key stakeholder:


In order that the Marketing Manager grows PrintCo printer cartridge sales by growing the mailing list…

Or, you don’t need to even use ‘In order to’… you can word it any way you like


Goal: the Marketing Manager wants to grow PrintCo printer cartridge sales by growing the mailing list…

The most important thing here is not the wording. It’ that we find a way of keeping the business value in the conversation and when we’re talking about the capabilities, we focus on the user. What I’ve described is just one way of achieving that.

It’s like a “theme” for the stories

Themes have been suggested by many as a way of grouping user stories. In this case, the ‘In order to…’ can be thought of as a theme for the stories – i.e. the theme is described in terms of business value. Stories, described in terms of the user capability and incentive/context, are injected into the “theme” as we identify roles and capabilities that deliver the business value.

Notice, that I thought about the “As a…” and “So that…” aspects of the user story first and then summarised the capability, yet the order in which I expressed them remained as normal. As Rachel Davies once highlighted to me, just because we think of these things in one order, that may not be the best order for a discussion with the people who will implement it.

Another way of putting this is that the “As a… I want… So that…” is optimised for the conversation that helps the product owner(s) communicate what is required to the rest of the team, not for the order in which we generally discover the information.

In Summary

As you can see, Feature Injection doesn’t encourage you to simply move the “So that” to the beginning and reword it with “In order to”. I can see why people do that. One possible reason is because the stakeholder intent has been mashed into a user story, but that loses the purpose of a user story. I can also see why that happens, because there wasn’t an obvious place to think or talk about stakeholder intent. Business-value focused themes give us that.

I hope this helps clarify a little about Feature Injection and how it relates to user stories… but remember, this is only the tip of the Feature Injection iceberg. Actually it’s just one of the outcomes of Feature Injection. Watch this space for more.

So, first things first, I want to take this opportunity to update the terminology I use…

Goals -> Tasks -> Actions
A useful technique used in User-Centred Design (UCD) and Human Computer Interface (HCI) design is Task Analysis. There are three layers of detail often talked about in Task Analysis:

Goal: What we’re trying to achieve which has one or more…
Tasks: The high-level work-item that we complete to fulfil the goal, each having one or more…
Actions: The specific steps or interactions we execute to complete the task.

Previously, the terms used by Kevin, myself (and several others) were Goal->Activities->Tasks. From now on, I’m going to use the UCD/HCI/Task Analysis terms Goal->Task->Action. It’s exactly the same model – just with different labels at the three layers of detail.

What’s wrong with your average behaviour spec?
Let’s look at a common example… The calculator. For convenience, I’m going to borrow this one from the cucumber website[1].

Scenario: Add two numbers
Given I have entered 10 into the calculator
And I have entered 5 into the calculator
When I press add
Then the result should be 15 on the screen

[1]note: I’m using this example for convenience and simplicity. The value of the example on the cucumber website is to demonstrate how easy cucumber is to use and not necessarily as an exemplar feature spec

What would you say the scenario’s name and steps are representing? Goals and Tasks or Tasks and Actions?

I’d argue that adding two numbers is a task and the steps shown above are actions.

Instead, I try to write the spec (or test) with a scenario-specific goal and the steps as tasks.

Scenario: sum of two numbers
When I add 10 and 5
Then I should see the answer 15


I.e.:
Scenario: <A scenario specific goal>
Given <Something that needs to have happened or be true>
When <Some task I must do>
Then <Some way I know I've achieved my goal>


Another Typical Example
Let’s apply this to another typical example that might be closer to what some people are used to seeing:

Scenario: Search for the cucumber homepage
Given I am at http://google.com
When I enter "cucumber" into the search field
and click "Search"
Then the top result should say "Cucumber - Making BDD fun"


Again this is talking in terms of actions. As soon as I’m talking in terms of click, enter, type or other user-action, I know I’m going into too much detail. Instead, I write this:

Scenario: Find the Cucumber home page
When I search for "Cucumber"
Then the top result should say "Cucumber - Making BDD fun"


Why does it matter?
In the calculator example, the outcome the business is interested in for the first scenario is that we get the correct sum of two numbers. The steps in the scenario should help us arrive at a shared understanding of what ‘correct’ means. How we solve the problem of getting the numbers into the calculator and choosing the operator is a separate issue. That’s detail we can defer. It may be better to explore the specifics of the workflow using, sketches, conversation, wire-frames or by seeing and using our new calculator.

So, expressing our scenarios in terms of goals and tasks helps the delivery team and the business arrive at a shared understanding of the problem we’re trying to solve in that scenario.

Expressing the scenario in terms of the clicks, presses and even fields we’re typing into is focusing on a solution, not the problem we’re trying to solve.

But there’s another benefit to doing it this way…

A Practical Concern – Maintainability
The first calculator example follows reverse-polish notation for the sequence of actions:

1. enter the first number
2. enter the second number
3. press add

If we put that detail in the scenarios, that workflow will be repeated everywhere – for addition, subtraction, division, multiplication… and anywhere any calculation is described.

What happens if the workflow for this calculator (such as the UI or API) changes from a reverse-polish notation to a more conventional workflow for a calculator? Like this:

1. enter the first number
2. press add
3. enter the second number
4. press equals

The correct answer hasn’t changed – i.e. the ‘business rule’ is the same – it’s just the sequence of actions has changed.

Now we have to go through all the feature files and update all the scenarios. In the case of our calculator that may only be a few files covering add, subtract, divide, multiply. For something larger and more complex this could be a lot of work.

Instead, putting this in the code of the step-definition means that this:

When ^I (add|subtract|divide|multiply) (.*) (?:and|from|by)? (.*) do |operator, first_number, second_number|
@calc = @calc ||= Calculator.new
@calc.enter first_number
@calc.enter second_number
@calc.send operator.to_sym
end


Would have to change to this:

When ^I (add|subtract|divide|multiply) (.*) (?:and|from|by)? (.*) do |operator, first_number, second_number|
@calc = @calc ||= Calculator.new
@calc.enter first_number
@calc.send operator.to_sym #moved up from the bottom
@calc.enter second_number
@calc.calculate #new action for the conventional calculator workflow
end


Nothing else would need to change – other than the product of course. By writing the steps as tasks, all of our feature files would still accurately illustrate the business rule even though the workflow of the interface (gui or api) has changed.

Taking your scenario-steps to task
So, taking this approach helps us to reduce our maintenance overheads. Putting the Actions inside the step definition makes our tests less brittle. When the workflow changes we only need to update our specs in one place – the step-definitions.

Of, perhaps, greater importance – by capturing the user’s scenario-specific goal as the scenario name and the tasks as the steps, the team are working towards a shared understanding of the part of the problem we’re trying to solve not a solution we might be prematurely settling upon. When rolled up with the broader context (expressed in the user-story and its other scenarios) it gives us a focus on solving the wider problem rather than biasing the solution.

Sometimes, at first, it’s hard to see how to express the scenario and is easier when people start by talking of clicks, presses and what they’re entering. And that’s ok. Maybe that’s where the team needs to start the conversation. Just because that’s where you start, ask “why are we doing those actions” a few times, and it doesn’t have to be where you end up.