Aligning agile requirements with commercial goals

We all know & love users stories in agile

Whether creating a new online service, software or mobile app, there’s usually a digital product studio with a well oiled and agile process that’s driving the delivery.

If you work in such a studio you have probably noticed that the daily parlance, revolves around user stories — the precursor to embarking on new agile projects or developing new product features (pre-sprint initiation).

The approach is gaining momentum quickly. From April 2014, the government (formerly a bastion of waterfall project delivery methodology) even has a recommendation to move to an agile environment: https://www.gov.uk/service-manual/agile

As ‘techies’, we love user stories because they feed beautifully into encapsulated technical requirements with accompanying acceptance criteria (and therefore optionally a BDD test) and are manageable as isolated features for the backlog. As such we have spent a lot of time refining our agile methodology around user stories. This is a summary of our approach to refine it further.

INVEST in good stories

We like Bill Wake’s framework for validating the quality of user stories (seehttp://en.wikipedia.org/wiki/INVEST_(mnemonic) for a brief overview).

Independent

The user story should be self-contained, in a way that there is no inherent dependency on another.

Negotiable

User stories, up until they are part of an iteration, can always be changed and rewritten.

Valuable

A user story must deliver value to the end user.

Estimable

You must always be able to estimate the size of a user story.

Scalable (small sized)

User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.

Testable

The user story or its related description must provide the necessary information to make test development possible.

OK, sold! But how to go about gathering them?

Until some time in 2013 Byng went through a series of “Definition” stage activities including workshops, interviews, sketches, user journeys and observation. Throughout this large post-it notes were put on the wall ready representing the backlog. This certainly brought that warm and fuzzy feeling in the people attending in getting ideas mapped out on a wall crystallising a product strategy.

Somehow though this didn’t quite feel like we really dug deep into the product and WHY the user stories were there on the wall from a product owner or commercial perspective. We all knew we put them there but if anyone was challenged a rambling explanation of how that linked back to the product tended to be delivered. The end-user was well represented but was the commercial goal?

In brief the commercial goal was usually reasonably well represented so long as the product owner was present but really this wasn’t documented. After some thinking and exploring new methodologies deriving requirements from commercial goals, we gave a new route a go…

Impact Mapping: Systematic goal related user stories

Cue, Impact Mapping — from their website:

“Impact mapping can help you build products and deliver projects that make an impact, not just ship software.”

The central principle of this approach is to prioritise product features based on:

  1. What are the various features that are important to users?
  2. How are they delivered? What is the interaction / functionality
  3. Who are these users, and crucially
  4. Why does this link to commercial / business goals (the impact)

By linking back to commercial goals, we found that the user stories ended up being pulled together in a language that can be understood and is inclusive of product owners and consultants, as well as drive meaningful requirements for designers and developers. We also found that all the stakeholders are less likely to get buried in the detail and over engineer the solution. Finally, we discovered an approach that takes into account assumptions which addresses the dynamic nature of business (other approaches tend to treat business as if it were in a vacuum or at a snapshot in time).

So how does Impact Mapping it work, I hear you say?

On first glance it looks much like a brainstorming exercise, (not a post-it note fest), see below:

One of the first things you’ll notice is that we start with commercial goals (the Why?) and work outwards, addressing the steps outlined earlier in reverse order, or nearly, see example below (where the why is 1M players).

Reading off the user story from the Impact Map give us a commercially aligned agile requirement!

Beyond ordering the map, hopefully from a quick glance at the example diagram you can also see that the Impact Map drives tidy user stories which link easily back to commercial goals or how it can unearth important product features. However, in order for this outcome, we need to set the right goals.

Using a “SMART” approach to drive goals

By putting a SMART goal at the hub of the impact map and driving requirements by users on that goal, we can be sure to get highest and most core priorities into the backlog. What also materialises is that there are other stakeholders in the journey who contribute to the goal and who are as important as the end-customer (e.g. sales staff are all too often de-prioritised).

SMART goal setting gives goals which product owners and business stakeholders can buy into

SMART goals are:

  • Specific — target a specific area for improvement.
  • Measurable — quantify or at least suggest an indicator of progress.
  • Assignable — specify who will do it.
  • Realistic — state what results can realistically be achieved, given available resources.
  • Time-related — specify when the result(s) can be achieved.

So now we have the impact map to open up the backlog, what next…

Impact mapping was developed by Gojko Adzic to shape the design of products for their clients (literature exists if you are in this camp). It has been adapted, we have used the model to shape technical requirements for clients using an agile approach (with the exception of launching ours or others new ventures, where we are doing both).

In the former case (as a technical studio developing new digital products), the final impact map gives us a basis to write technical requirements which closely ties into user needs and our clients business needs.

While Impact Mapping helps drive the MVP Lean Startup methodology combined with Kanban helps bring the benefit of validated learning to any changes.

Tools to use for Impact Mapping…

We opt’d for Mindmeister in the end — there are many “mind mapping” solutions out there: http://lifehacker.com/five-best-mind-mapping-tools-476534555

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.