User Stories Unplugged Part 3: These are not the requirements you are looking for…

In Part 1 of this series I discussed what user stories are and, as importantly, what they are not. In Part 2 I further explored how they are used as a collaboration tool. In Part 3, we look at why User Stories are not the requirements and propose a method for documenting them, if needed, given this assertion:

User Stories are not the requirements or the documentation and they die when they are done and are not updated.

“Stories aren’t a written form of requirements; telling stories through collaboration with words and pictures is a mechanism that builds shared understanding. Stories aren’t the requirements; they’re discussions about solving problems for our organization, our customers, and our users that lead to agreements on what to build. Your job isn’t to build more software faster: it’s to maximize the outcome and impact you get from what you choose to build.” ― Jeff Patton, User Story Mapping: Discover the Whole Story, Build the Right Product

User Stories have a short turbulent life.

They are born, sit on a backlog for a while, maybe move up and down it, then get chopped into bits, refined, developed and destroyed.

This is why they are not the requirements and not the documentation.

They are not the requirements because they are the promise of a conversation where the ideas we have are explored and refined. These are the requirements.

Some documentation will usually be needed to support the requirements and may be included with the User Story but they will need some other home once done because User Stories die.

For example, we may have one story that implements a basic search. Another comes along and adds a few more rules to the algorithm. A further one comes along, adds some more but also requires our now long running search engine to perform much faster.

If we want to now understand how our search feature works, we will have to assemble a history of user stories and infer what the search should do based on this. These are often conflicting as the results of the basic search may no longer apply when we have added more complexity to the search engine.

Imagine if to understand how your TV worked you had to read through all the notes produced along the way that built it!!

One way to overcome this problem is to produce and maintain alongside the birth, refinement and death of User Stories, an Executable Specification of each feature in the product. It is a specification of the feature as it can include acceptance criteria, descriptions, examples and images of all the screens and designs derived from refinement of user stories for that feature and it is executable in that if these examples are written in a Domain Specific Language (DSL) like Gherkin, then can be executed as automated tests upon our product using a test framework like Cucumber.

As new stories come along and change the behaviour of the feature we focus the discussion on the existing executable specification and make the changes to that. Only using the story as the token of the conversation with some description of what is changing.

The example below shows a feature file for withdrawing cash from an ATM.

The feature file also includes markdown language syntax to allow us to produce a nice readable specification.

# Withdraw Cash

Feature: Withdraw Cash

## History

Version | Date | Author | Comment | Jira Ref
— — — — | — — -| — — — -| — — — — | — — — —
0.1 | 15/01/2018 | Harry Benson | Initial draft | [HA_382](

## Table of Contents

## Overview
As a existing banking customer
I want to withdraw cash from my account
So that I can go to the pub on a Friday night

## Acceptance Criteria
- Can withdraw cash up to £250 a day
- Can only withdraw multiples of £5
- Can only withdraw up to my overdraft limit

## Screens

## Links
[Bank ATM designs](

## Assumptions
- Only deal in £5 notes

## Scenarios
### Withdraw cash in £5 increments up to £250 a day and within overdraft limit
Scenario Outline: Withdraw cash

Given I have “<balance>” in my account
And I have “<overdraft>” limit
When I “<withdraw>” cash
Then I am given “<cash>”
And I have “<remaining>” balance

Examples: Can withdraw up to £250 a day
| balance | overdraft | withdraw | cash | remaining |
| £500    | £0        | £250     | £250 | £250      |
| £500    | £0        | £255     | £0   | £500      |

Examples: Can only with withdraw in multiples of £5
| balance | overdraft | withdraw | cash | remaining |
| £500    | £0        | £4       | £0   | £250      |

Examples: Can withdraw cash up to overdraft limit
| balance | overdraft | withdraw | cash | remaining |
| £100    | £250      | £250     | £250 | -£150     |
| -£150   | £250      | £250     | £0   | -£150     |

The combination of these two approaches allows us to execute the specification as a test using cucumber and also view the specification using a markdown reader (or export it as a pdf or html page).

The results of running the test are:


And viewing the feature file using a markdown reader:



Spec3Now we know what User Stories are, how they are used, and how they feed into providing executable specifications we can move into Part 4 of this series to bring it all together to look at a day in the life of a User Story.


User Stories Unplugged Part 2: All Together Now…

In Part 1 I talked about what User Stories are and, as importantly, what they are not. In Part 2 we unpack how they are used by the team.

User Stories are not owned by any single team member…they are a collaboration tool…they are the promise of a conversation.

If you find your Business Analyst or Product Owner head down typing stuff into Jira there’s probably something wrong with how you’re using User Stories…or not using them.

User Stories are primarily a tool for collaboration. They are a mechanism for breaking the problem down into smaller more manageable chunks — these chunks then acting as the focus for collaboration between the team and the customer.

“Handing off all the details about the story to someone else to build doesn’t work. Don’t do that.” ― Jeff Patton, User Story Mapping: Discover the Whole Story, Build the Right Product

In the years that have passed, some of the original intention of Agile is often overlooked — to get developers and customers working together — those with the problem working hand and hand with those who can solve it. The User Story arose out of this intention as the token that is taken through refinement, development and release. Often known as the 3 C’s: the token is a card, the refinement is a conversation and an agreement that what we have built meets our understanding is the confirmation

It is a teams understanding we are seeking not a Business Analysts or a Product Owners. The Business Analyst or Product Owner is there to help the team understand the problem. This understanding is achieved through refinement with customers and members of the team and is often referred to as The 3 Amigos. This isn’t a process, it’s the collective term for representation at refinement from the customer, from the developer and from the tester. It’s often not enough as representation can also be required from User Experience Design, User Research and others.

The approach to refinement of user stories differs per team and per story. The context you are in will dictate how you go about getting this rich understanding amongst your team:

“Effective teams with third party dependencies, or those that rely on external specialist knowledge, generally dedicate one or two people to investigate those dependencies a week or two before starting a story. The results of the investigations are a great starting point for the story analysis discussions. Some teams analyse stories twice as a group: once a week or two ahead of the iteration to collect open questions and focus the upfront investigation, and the second time just ahead of the iteration to communicate and agree on the details.” ― Gojko Adzic, Fifty Quick Ideas to Improve your User Stories

The Business Analyst or Product Owner is often essential in enabling this understanding within the team. They are the glue that helps the team stick. They facilitate the conversation, expose examples where needed to help clarify the requirement, keep the discussion focussed on the problem being solved not the detail of the technical solution, and keep bringing and testing the understanding we have of the problem…as a team…not as an individual in a role.

To do this the Business Analyst or Product Owner needs to have a trusting and mutually respectful relationship with the customer and with the developers and testers. These collaborative sessions can be intense so they need the skills to facilitate difficult, rich and exploring conversations without allowing them to veer off at the whim of a strong personality.

They also need to be short and focussed. We are looking at many 15–30 minute sessions rather than half-day workshops.

It starts with a brief introduction of the next story from the Business Analyst or Product Owner, explaining who is it for, what is it and what is their goal. They clearly communicate the user needs and / or business reasons why this is important.

They give an initial indication of what we should keep our eye on and potential problems and concerns are identified and discussed. This allows the team to explore things we don’t want to or shouldn’t do and where we think there could be misunderstandings.

The Business Analyst or Product Owner also gives some high level indications of what the story covers, allowing others to contribute. This begins an exploration of the acceptance criteria.

Any sketches that have been done beforehand are brought forward (e.g. user interface, design or data model sketches). If not, then some time may be needed to address these but more often than not a separate more holistic design session is needed.

They then explain some happy path examples and a couple of negatives but encourage others to join in and provide examples that give a rich understanding of the requirement. They jump between refining acceptance criteria, sketching new concepts and giving more and more examples.

A bit of clarity here by what I mean by examples. We are trying to give concrete examples of behaviour. How the product behaves under certain conditions and what we expect to happen when these conditions get broken. The examples do not need to be exhaustive but do need to be illustrative. They need to show data and action and how the system reacts to this data when this action is applied not just be declarative statements of functionality.

This is often misunderstood as functional testing. It isn’t this — it is testing our understanding of the problem domain. Therefore, it is a requirements technique over a testing one and more importantly it is a collaboration tool not a documentation tool.

When all this chit-chat is completed…when the team believe they have a rich understanding of the requirement they review the acceptance criteria and examples to look for any gaps before concluding the discussion, marking the story as ready (for development / Sprint planning) and moving on to the next story.

What about documentation? How do we document out understanding of the requirements so we don’t forget?

We are Agile right? We don’t need to do this?

In part 3 of this series I’ll discuss how requirements may get documented in an Agile team and set the record straight.

User Stories Unplugged Part 1: Won’t the real User Story please stand up!

A backlog can be full of things that claim they are User Stories but aren’t really.

Here I try to think why this could be….

Not everything is a user story and they don’t have to be written in a particular way…they are an idea of something a user might want to do on a system or what a customer or stakeholder might want done on users of a system.

Things I’ve seen done under the banner of user stories that generally aren’t really are:

· Technical activity (often called Technical Stories)

· Project Management activities

· Development tasks

· Dependencies

· Non functional requirements

· User Needs

Let’s look at these to understand first why they aren’t and secondly why teams do this. Then maybe we can question ourselves a bit more and do the right thing instead.

But first…

“Right now you should stop whatever you’re doing and say this out loud: Stories get their name from how they’re supposed to be used, not from what you’re trying to write down.” ― Jeff Patton, User Story Mapping: Discover the Whole Story, Build the Right Product

Stories are not the requirements; they are not the documentation…they are a collaboration tool, the promise of a conversation. They are the token of learning and of development.

They start as an idea of something the product should do, more precisely, something a user should be able to do and derive some value from doing. I say user but I really mean user (person using product), customer (person paying for product) or stakeholder (person impacted by the product).

With this in mind they are generally a verb phrase. For example, our bookworm (user) may want to search for book, view book details, add to shopping bag or checkout shopping bag and our advertising executive (stakeholder) may want to advertise what other users buy to entice our bookworms into buying multiple books.

The user should recognise the action and the value they get from it. For example, they want to view book details so they can see if the book is something they’d be interested in reading. Given that understanding we can then frame the forthcoming conversations around what it would take to meet that need.

That conversation may be sometime coming. When you see just the verb phrase amidst a plethora of other stories some time later then it’s often the case you forget what the story meant to achieve in the first place.

Template Zombies

We are familiar with the template “As a {user}, I want {capability} so that {goal/value}”.

This template isn’t there for writing better user stories. It is there to act as the prompt for the conversation. If it’s not needed then don’t use it. If you could come up with your own style that’s more effective, then do this instead.

Just because you use the template doesn’t make it a user story. You don’t write things as user stories…you identify ideas for capabilities in your product that users would value which you tell stories about at some point in the future. These are your User Stories.

Think of User Stories as survivable experiments. We implement and release user stories in a safe place to fail with the intention of learning.

“By approaching stories as survivable experiments we can shift the focus from technical complexity to expected outcomes and learning. This prevents technical stories, stories that are too small to go live and stories that business sponsors don’t care about.” ―Gojko Azdic, Fifty Quick Ideas to Improve your User Stories

I believe I am often overly critical of the use of the template. Not because it’s bad when applied to user stories, it’s bad when we keep doing the same things as we’ve always done, just because they are written using this template we pass them as user stories and claim we are Agile.

But in my defence, I’m not the only one….

“those monstrosities sometimes known as technical stories.”

“tasks were masked into fake user stories, written in the typical story format. ‘As a QA in order to test faster I want automated log error reports’ is not a user story. It might be in a story format, but unless you are building software for testers (these people were not), there is no good reason why you’d want to capture tasks like that.

Writing such tasks as user stories makes them compete with externally valuable work, and they’ll always lose. “ ―Gojko Azdic, Fifty Quick Ideas to Improve your User Stories

You may have to do these technical activities, these project management activities and manage these dependencies and they usually take a bit longer than typical sprint boundaries. Treat them as the things they are and manage them accordingly. Ideally they contribute towards the development of a user story and can be done in a short timeframe. In these cases, then either treat them as sub-tasks of a story (if doing Scrum) or as part your workflow (if doing Kanban). They also don’t need to be written in a funny template driven way.

And if they really are sub-tasks and you can’t get the story done in 2-week Sprints then split the story so you can. Maybe you can defer that complex search algorithm or delay allowing payments for certain types of card or iterate around a simple user interface until it fully meets the needs.

Only do what’s facing you. Don’t start designing and building things in for the fear of some future requirement or to produce some anticipated reuse for some need you don’t fully understand. Keep it clean, keep your options open and Keep It Simple (KISS) because chances are You Ain’t Gonna Need It (YAGNI).

Some words of wisdom related to this:

“we shouldn’t add features until they are needed. Forget just in case; develop just in time.” ― Mary Poppendieck, Leading Lean Software Development: Results Are not the Point

“There are few endeavors in which it is more important to keep options open than in software development. In Chapter 3, “Decide as Late as Possible” ― Mary Poppendieck, Lean Software Development: An Agile Toolkit: An Agile Toolkit

Tricky relationship with NFR’s

Turning our attention to Non Functional Requirements (NFR’s). These are a tricky subject as they should be handled appropriately under different circumstances but usually not as User Stories.

Let’s say all screens have to load within 2 seconds. That’s an NFR. How would you handle this? Would you implement a bunch of your screens then at some point in the future say — now let’s meet the 2 second rule….

If you do, which I would advise against, then it’s reasonable to think of it as a story. This is because you will do the refinement to understand it then implement and test it in a single sprint. Not ideal. And what will you do after you’ve implemented a whole new bunch of stories…open it again? Write another story?

This scenario is usually driven by lack of skilled performance test resource so this type of testing is delayed until the resource is available or until the test environment is.

When this is the case the usual way of dealing with it is as a development activity done prior to a release.

If you do have the skills and resource within your team, you will ideally test this on every single story that has a user interface. The best way of doing this is to include it in your Definition of Done. So to be recognised as being Done within a Sprint each and every story will need to meet this constraint.

In these cases, the NFR need not feature on your backlog at all.

If, however, the NFR only applies to one or two stories (e.g. Search for Book may need to return results within 5 seconds) then these NFR’s should be included as Acceptance Criteria of the functional story.

Emotive Needs and Functional Stories

Finally, we have User Needs. User Stories are an abstraction of a users needs for the service and there is often a confusion over what a user need is and what a user story is.

The need to be confident that my book purchase will be something I’m interested in is at one level of need — it is reason, the problem, the motivation that lies at the heart of what we design. The ability to view the book details, read a sample chapter, see other reader’s reviews of the books are the needs the user has to meet that higher order need. These latter needs are the beginnings of our user stories.

See the difference?

One is emotive and gives some motivation. The other is functional…actions that help achieve those emotive / motivational needs.

As such, I like to use User Stories for the lower level needs and some other mechanism for the higher order needs (e.g. Hypothesis, Insight Statements or Problem Statements). They aren’t Product Backlog items, we don’t build them, we build the stories that meet this need once we have proven the hypothesis.

We may use higher order needs in road-mapping and prioritisation or even as a Sprint goal but they aren’t used in the same way as stories. I find divorcing the emotive/motivational needs from the action needs helps to separate out the reasons from the actions, provides a backdrop for innovation and clearly shows how those ideas we have had meet those higher level needs.

Flow: Value, Visualisation, Verification, Vision

Achieving Flow means getting out of your comfort zone and being fearless in your adoption.


Flow starts with organising, motivating and specifying towards the flow of value to your ultimate customer.


Organise and motivate for Flow then visualise it flooding through your value streams.


Bad features can Flow too. Constantly verify the value and verify the product.


Repetition breeds boredom. Boredom eradicates Flow. Flow needs to be sustainable. Maintain Flow by focusing on a bold vision of perfection. Then pursue it relentlessly.


Group Flow

jazz20bandRenowned psychologist Mihaly Csikszentmihalyi describes the optimal experience as being in the Flow state. In this state, the individual is totally immersed in the activity they are performing, they are focused on it totally, fully concentrating on the task at hand. Self-consciousness is lost and time seems to stand still or go by unnoticed.

To achieve this state of Flow, the skill of the individual and the challenge posed by the task are high (but not so high as to be unachievable), the goal is purposeful and there is clarity in what you are trying to achieve and progress towards it is received immediately and constantly.

Henrik Forsgård extends this in his TEDTalk Group Flow[1], where he draws comparisons to a Jazz Ensemble on how Flow is achieved within a team environment.

To achieve Group Flow, the skill levels of the teams individuals need to be similar, they need to understand each others abilities, position and motivations and know that their teammates are interested in what they are doing. They need social feedback on an affective (emotional) level that helps develop rapport and build trust within the team and, just like individual flow, they need clear goals, immediate feedback on progress and a challenge that matches their collective skill level.

When Group Flow is achieved the self becomes suspended and extends to the group; the emotional state of the individuals becomes contagious and spreads through the group; the group develops a collective sense of purpose, believing they now belong to something greater and they start to institutionalise the ceremonies / rituals that they used to develop rapport and the Group Flow experience.

Satisfying these conditions brings individuals together in a joyful and purposeful endeavour. This is Group Flow.

Many of us have been in teams where Group Flow has been achieved and, having achieved it and the recognition it deserves, we have gone on to institutionalise the approach by describing our practices, artefacts and ceremonies in the belief that other teams would follow our rituals in order to attain the holy grail of optimum performance through Group Flow within their team / organisation.

When we institutionalize these practices and ceremonies we are attempting to shape the activities and team structures to foster flow whilst removing the impediments that obstruct it.

If we look to Scrum or XP we see a number of practices, ceremonies, artifacts and roles that have this intent but lack the rituals that are needed to develop rapport and hence truly develop Group Flow.

It is these rituals that are overlooked and for obvious reasons.

For example, which activity is more likely to develop rapport in a team:

  1. Daily Stand-up
  2. Retrospective
  3. Having a Scary-Mask day at the office

I’d argue the first two are there for synchronization and continuous improvement but the third will help build rapport within the team more effectively. This generates affective social feedback.

And this is why it’s difficult and perhaps another reason why there are so many reports that Agile didn’t quite do what it said on the tin. In no Agile process framework have I come across the Scary-Mask day ritual, or the wear odd-shoes day activity for that matter (though that may have been an accident that sparked an epidemic). They are intrinsic to the team and cannot be institutionalized.

So let’s assume you have achieved Individual Flow and this has been extended to the team and the characteristics of Group Flow can clearly be observed.

Job done!

However, the balance in achieving Flow is intrinsically fragile for the individual and the group.

For the individual and a team, if skills begin to exceed challenges, which they will surely do as the individual and team becomes more experienced, then boredom sets in and Flow is lost.

For Group Flow, the institutionalisation of the practices leads us to become focused on the process rather than on team rapport, the practices become repeatable rather than engaging and team mojo begins to wain. In a one year project of 2-week iterations, that’s 26 Sprint Planning sessions, 26 retrospectives, 26 Sprint Demos and 220+ Daily Stand-Ups. Just how many do you need to do for them to become repetitive and dull?

Once boredom arrives, Flow is lost.

We therefore need to provide individuals with a series of graded challenges, able to accommodate a person’s continued and deepening enjoyment as skills grow[2].

We also need to set the team a vision for perfection they can continually strive for where all practices become subservient to that vision.

And we need to wear scary masks now and again.


[2] Handbook of Positive Psychology, 2005, Chapter 7, The Concept of Flow, Jeanne Nakamura & Mihaly Csikszentmihalyi

Change by Assertion

Metrics should also be observed and not set…especially within a contract framework. We are after open and honest measurements to gauge how we are doing and support decision making. If we impose penalties based on failure to hit certain measures then suppliers have a skill at bending the reporting of these measures to suit and hit their targets….thereby obfuscating this critical information.

Steve Handy's Blog

I’ve been involved in process improvement for around twenty years, I think I’ve had some successes.

This is a problem “I think I’ve had some successes” ?
Last year, I was having a conversation with my friend and colleague about how we could approach a particularly tricky question, Mike and I were challenged with understanding the performance and productivity of a large client organisation’s software engineering department – this is difficult to measure.
Our conversation turned to metrics and reporting and we were both struck, and concerned, by the realisation that the approach in the software industry to improving the way teams work is based on the assertion that a particular approach is just “better”. Customers should “have faith”  that if they stick with the recommended program things will improve, many process improvement approaches dismiss an evidence based approach to process improvement as being too hard, conveniently ignoring the issue…

View original post 221 more words