Talk given at Agile on the Bench 15 April 2015

I’ve never been a huge fan of user stories

‘As a team member, In order to know what the hell I’m doing, I need a vast and sprawling backlog of 50 million user stories entered into Jira’.  Said no one. Ever.

‘As a team member, In order to contribute to high value business outcomes, I need purpose, direction, context and shared understanding.’  Said me.

I think I’m having a mid-life crisis. I miss the olden days

I miss the structure

• Section 4.3 had a process flow or diagram
  • Section 4.3.5 had a use case and some key interactions.
    • Section 4.3.5.1 described a scenario
      • Section 4.3.5.1.b described some alternate paths
        • Section 4.3.5.1.b.ii showed some error handling

I miss the context

Remember the functional decomposition tree? In my functional specification, there was a place for everything and everything had a place. Each piece of functionality was neatly broken down into smaller bits of functionality to help me understand. A massive 456 page hierarchy.

I miss the relevance

Remember the V Model? We had different outputs appropriate for different audiences created by different team roles based on different levels of elaboration. Each level of analysis output had it’s partnering test documentation where the rules were recaptured as tests something like ‘verify that <insert statement from analysis doc here>

I miss the analysis

Years of analysis experience and a multitude of techniques went into massaging Business requirements into functional specifications and design documents for us to build our solutions upon.

Somehow in our new world of iterative software delivery, analysis has become a bit of a dirty word. I think we hold analysis responsible for all the pain we experienced in the olden days.

It’s not analysis’ fault

Analysis was never the problem. The problem was that the structure, context relevance and analysis of the olden days were all based on a pre-conceived solution rather than the goal. Because of this we had to deliver the entire thing in one go to achieve any of the benefits. 2 years later the world had changed.

The problem was that we used to work in silos, delivering ambiguous outputs with lots of hand-offs and too much opportunity for misunderstandings. Inevitably in testing phases we uncovered loads of requirements defects and projects got delayed.

The problem was that there was loads of wastage. Huge documents were produced which were indigestible for reviewers. Each individual would have to re-learn and re-analyse the subject matter to produce the next document in the chain. Testers would find gaps in specifications as they considered how to test the system, causing costly late changes.

Now we do things more collaboratively, we have more conversations. We’ve reduced hand-offs and opportunities for misunderstanding & misinterpretation. We use BDD techniques to collaborate around real-world examples to achieve shared understanding and we reduce wastage by using tests as a specification.

We still need analysis

I think we’ve recently started realising that we need to do the analysis. A conversation from a post-it note isn’t enough. We need to go through the process of turning the business need into a specification (or test) to begin implementation.

The word analysis comes from the Greek ‘to loosen’. It literally means to break down

‘User Story Splitting’ is just a clean way of saying analysis.

Just because we think we’re ‘Agile’ doesn’t mean we’re immune to the horrors of the olden days. If we do too much up-front breaking down of our stories, we can end up in user story hell.  Too many broken down user stories on a backlog represents wastage.

It’s too much up-front breaking down that got us into trouble in the first place.

The whole point of having atomic user stories is to enable us to deliver them incrementally or iteratively in order to get business value as early as possible. We only get value from our iterative software delivery approaches if we are always working on the most important thing.   In order to do this we need to know which scenarios, stories and examples are the most important ones.

Design Thinking

Design Thinking starts with the goal instead of a solution. It investigates alternate paths to achieve that goal and then refines and tests options.

Design thinking is iterative and is described as a sequence of steps (different sources):

• Empathise, focus, ideate, prototype and test.
• Define, research, ideate, prototype, choose, implement, and learn.

There key aspects of Design Thinking are:

Analysis and Synthesis. Literally meaning to break down and put together. Analysis breaks down the whole into components to examine it, and synthesis puts the conclusions from that activity back together to form a coherent whole. They always go hand in hand.

Divergent and Convergent Thinking. In the divergent phase we examine options and generate ideas. In the convergent phase we rationalise our ideas and prioritise the best ones. We create choices then make choices.

In the olden days we may have been doing some pretty good analysis and synthesis as we generated our 456 page functional specification documents. We’d just be doing it on our own, coming up with our own interpretation of ‘synthesis’ not necessarily the same as the next person.

We may have been doing some good convergent thinking, but unfortunately converging on features that delivered little business value or would never get used.

Asteroids

Jeff Patton in his fantastic book ‘User Story Mapping’  compared splitting user stories with the 1980s game of Asteroids.

In Asteroids you start with some really big, asteroids moving around the screen and you have to shoot them up without being squished by them.  As you blast them, they break down into smaller asteroids and start moving faster, and as you break those down they get faster still. The more small, faster moving asteroids you have flying about, the more likely you are to get squished.

You need to pick off the big ones, one at a time or you’re a goner.

When I read this it struck me that this process has a Design Thinking element to it. After we have exploded the big asteroids (divergent thinking) we need choose which one to blow up next (that’s the convergent thinking part) and leave some slower moving ones still floating. This is iterative not just from a story by story perspective, but for each hierarchical level of elaboration.

We only break down what we need to enable us to start the learning process.

It’s this iterative process of creating choices > making choices, that helps us navigate towards value as early as possible. 

We need to start with the goal. We need to break goals down into key business outcomes and impacts, key interactions that help deliver those impacts, then important scenarios and examples. Breaking things down based on the goal helps us stay focused on a shared vision so we can make good choices.

Like a good story, we want things to make sense in the context of a meaningful narrative, so that they are not disconnected from the bigger picture. In order to do this we should embrace analysis techniques like process mapping,  interaction diagrams and User Story Mapping.

This is an excerpt from Jeff Patton’s User Story Mapping Book.

This recently helped me understand that a story doesn’t have to be a disembodied post-it note in a particular format. All of our outputs at each layer of elaboration are stories, if we use them in the right way. (I like them more now)

We’ve got pretty good at divergent thinking practices in recent years, particularly brainstorming and splitting User Stories, but we need to support this with more convergent thinking practices.

Gojko Adzic’s Impact Mapping technique uses Design Thinking to explore options and create choices to deliver Business impacts and outcomes. It helps us create a hierarchical product roadmap based on the goal.

This technique is fantastically effective, but the real benefit lies in converging on the next Business value increment or learning milestone that we should focus on.

Other techniques like User Story Mapping include really useful convergent thinking elements. Jeff Patton suggests considering opening game, mid game and end game versions of key interactions. This helps us get feedback at the earliest possible opportunity and defer some of the analysis till later.

We are also doing convergent thinking when we achieve shared understanding.  Collaboration using real world examples helps with this, particularly if we get good at choosing the most important ones to implement first.

Final thoughts…

In the olden days analysis was about functional decomposition of a solution. This decomposition created a hierarchy with context, but only told us where we started – which wasn’t that helpful

In the new world, rather than decomposition our analysis is like navigation. All nodes of our roadmap are linked to the goal. Our map is telling us our destination and options as to how to get there. – Much better.

So analysis is not the bad guy, we just have a new paradigm for analysis activities.