Asteroids and Design Thinking

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 described a scenario
        • Section described some alternate paths
          • Section 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

Screen Shot 2015-04-15 at 19.26.44

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.


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.

impactmappingGojko 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.




6 thoughts on “Asteroids and Design Thinking

  1. Jeffrey Davidson

    I’m not sure what’s going on, but it feels to me like there is a resurgence of analysis in the software world. Do you feel the same thing, Jenny?

    Truth is, I loved being a business analyst. I loved our techniques for tearing apart and building ideas. I loved how we built structure around concepts and tried to uncover and fill all holes. It was a great logic puzzle and lots of fun. I miss those days.

    We differ on user stories a bit. I don’t have a huge problem with user stories, in part because they are so easy to work with. I love that part. Heaven knows that no one besides a BA ever loved a specification document! But yes, something is still missing.

    Feature Injection fills in a couple of the current gaps, though it’s not used often enough. Impact Mapping is both great and needed, though it solves different problems.

    Anyway, I like your focus on design thinking. In fact, this weekend I coined the phrase *Feature Designer.* I think it’s what good analysts will want to be called. (See Tony Heap’s post & my comments,

    The point is, we need to know more about the why. We need to deal with how features add value and how they need to be put together. We need both a higher framework and better decomposition. And I need to finish Patton’s book!

    Thanks for the post. I look forward to continuing the conversation.

    1. jennyjmar

      Hi Jeff, I completely agree with your comments about decomposition and framework. Re User Stories, I guess the main thing that turns me off is the potential for lack of context and also the temptation to raise them all in Jira to track work. For our team that has always created an unnecessary overhead. What we have found is that we work better when we collaborate (and assign work) based on examples rather than stories. For me this implies that we have already wrangled with them a bit and decided on a subset of high value examples to implement. Instead of brainstorming User Stories and then arranging them into a map, we work the other way around, considering key interactions and flows, what a ‘dream demo’ might look like, and then collaborating on specific examples which help us get some feedback and learn stuff at the earliest opportunity. So we have key interactions in our dream demo that probably represent user stories, but we don’t bother writing them up or tracking them because we only plan on implementing a subset of examples at a time.
      We support this with what we call ‘data personas’ which are a cornerstone of our collaboration. Our examples are heavily based around the different variants of real-world data that drive our solution, we identify these really early on, get famiilar with them and use the same data examples from unit tests through to client demos and living documentation. As we move through the development process our data personas extend and start to drive the data model and inform the design… but I guess I’m into the realms of a completely different blog now….. 🙂 Thanks so much for being interested!

      1. Tony Heap

        Nice article Jenny – I think we are on the same wavelength – design thinking is the way forward, and I don’t think there is nearly enough of it (I don’t think there was even before agile and user stories came along). More of my thoughts on design thinking on my own blog at

        @ Jeff – thanks for the call-out!

  2. tonyheap1

    Nice article Jenny – I think we are on the same wavelength – design thinking is the way forward, and I don’t think there is nearly enough of it (I don’t think there was even before agile and user stories came along). More of my thoughts on design thinking on my own blog at

    @ Jeff – thanks for the call-out!

    1. jennyjmar

      Thanks Tony, I liked your article on BADM too, particularly ‘the importance of feature splitting – the conscious process of splitting features into sub-features in order to for delay (or avoid) the delivery of low value functionality’ I couldn’t agree more! 🙂

  3. C J Marsh

    Excellent article, thanks. I’ve also found that teams start using backlogs and user stories to remove constraints, but often end up actually constraining themselves due to lack of up-front analysis and unstructured requirements.


Leave a Reply