Getting Beyond 'Good Enough'.
A User-Goal based Framework For Agile Delivery.

Agile delivery typically focuses on the prioritisation and development of user stories. Often the focus is on developer throughput and misses the overall value proposition of the software from the perspective of the end-user. My talk introduces a user-goal based framework for setting up and managing agile projects for success. It introduces an approach to Goal-Driven Development that allows stakeholders/Product Owners to take a user-centered approach to delivery from requirements capture, through planning and into development to deliver software that delights the user.

A Few Of The Key Concepts From The Talk:

Setting-Up Projects For Success
Minimal Viable Product
User-Test Driven Development
Goal Burn-Down
Experience Innovation - Learning to Pivot (The Concept of Local Maxima in Design)
Helping Teams Get Beyond "Good Enough"

History of this talk

I am particularly proud of the way the ideas in this talk continue to evolve. I have successfully presented these to a variety of different audiences (agile conferences, business analysis conferences, UX conferences ect).

Whilst the core of these ideas remain the same, many have since been extended and refined. In particular:

I now recommend identifying goals by exploring hypotheses. This encourages a culture of measurable success metrics and allow these ideas to tightly integrate with Jef Gothelf's hypothesis-based LeanUX and Eric Reiss's lean-startup approaches.
When I first gave this talk, I used the term "Experience Refactoring". Following a heated debate with Martin Fowler we agreed that the term "Experience Innovation" was a better fit for what I was trying to describe. Now I realise that the best explanation of this phenomena came from Josh Porter when he talked about the idea of "Local Maxima" in design. Further to this was the idea of "the Pivot" in the lean startup movement. In essence the idea is "to iterate in small steps BUT innovate in daring leaps!"

Downloads

Get the slides here
UXhh made a nice podcast of the talk here

Some Additional Thoughts on StoryMapping

In this talk I introduce one of my favourite tools: the goal-based storymap. I actually started using storymaps before Jeff Patton's inaugural article first explained the idea in the context of Agile backlog management. I started storymapping after looking into alignment diagrams and mental models from Indi Young and adapting the ideas. Over the years, my storymaps have evolved into what I use in projects day-to-day. Apart from Indi, the stuff from Eric Reiss and Jeff Gothelf on the Lean Start-Up and LeanUX have helped me further refine my approach.

Obviously I would never push a prescriptive process but several people have asked me how I go about putting these things together.

My current approach to creating a storymap is something like this:

1) Start By Brainstorming Several Hypothesis

I start by facilitating workshops to generate several business focused hypothesis. This forces the conversation to revolve around measurable learnings and outcomes (LeanStartup style). I have found the format championed in LeanUX by Jeff Gothelf for documenting hypothesis helpful for this:

We believe that...
[ Building this capability ]

For...
[ These people ]

Will achieve...
[ This outcome ]

We will know we are successful when we see...
[ This signal from the market ]

Note that these hypothesis are not "story-level" constructs. They are targeted at the epic or broad capability level. These hypothesis are also NOT what I term a goal on a storymap - they end up becoming the higher-order success criteria for each goal and in this way we ensure that a metrics based approach to validation of our solution is put in place from the outset.

2) Allow The Goals To Emerge

Next, the goals are identified through affinity mapping (groupping and labeling!) of the hypotheses. In this way, the right goals tend to emerge, their higher-order success criteria is defined within the hypothesis and key areas of capability can be identified. It is often helpful to quickly bullet point key areas of functionality and key user journeys under each goal (that would help achieve them).

Goals are named in the format of a few words. They need to be descriptive statement of intent (they should make sense to a non-technical person if you shouted them across the room) BUT they should be solution agnostic. This allows the team room to pivot within delivery as the way to achieve the goal in software is not prescriptive.

3) Write Stories Under Each Goal

By using the bulleted capabilities and user journeys as a guide, story generation can begin. Ensure that you include stories to explicitly capture any metrics that were identified in your hypothesis. This is the magic "design-thinking" moment where teams tend to switch from divergent to convergent modes of thinking.

As...
[ persona name ]

I want...
[ this feature ]

So that...
[ justification/rationale ]

Stories are the nitty-gritty currency of delivery throughput. These are the things that developers like to work on. They should be I.N.V.E.S.T.able (Independant, Negotiable, Valuable, Estimable, Small / Similar-Sized & Testable).

Many teams try to shortcut this approach by jumping straight into a master storylist generation during project inception. This is a typical case of the "urgent crowding out the important"... Project managers know that stories need to be created for estimation and capacity planning so want to get on with these straight away. Personally, I have found that jumping to story creation without first spending the time thinking about the higher order goals and hypothesis is a surefire way to lose sight of the big-picture once you are in the cut and thrust of agile delivery.

4) Layout the Storymap

The story map is constructed with a list of Goals in priority order from highest to lowest priority.

Against each Goal is a number of hypothesis to be tested. The "market outcomes" from thesehypotheses are essentially the success criteria for the goals.

Stories are listed against Goals in priority order from highest to lowest priority.

This is where the light-bulb tends to come on. Seeing a storymap in front of them, product owners are able to talk in the currency of stories and goals whilst retaining their big-picture vision.

5) Prioritisation for MVP (Minimum Viable Product)

Instead of scoping in response to velocity (and encouraging a points-focused culture), have some tough conversations up-front to help understand MVP.

Which of these goals could we NOT achieve and still be successful?

How well do we have to achieve this goal in order to be considered successful?

Remember its just a map!

Once established a well constructed storymap tends to become quite a central information radiator. It can be used to help facilitate re-planning and scoping discussions. It can be used for communicate the "big-picture" to people (very useful for senior stakeholders or onboarding new team-members). It can be used to track progress against overall objectives (goal-burndown)... and much much more.

Have fun with them - and let me know what you think!

Presented at

The 10 year anniversary of the agile manifesto being signed saw the original signatories return to salt-lake city for this conference. This was an amazing conference for me from a personal perspective - Its not every day you get to present to Martin Fowler, have the opportunity to exchange ideas on leadership with Jim Highsmith or talk AgileUX with Jeff Patton!

It was here that I began to realise that my ideas on AgileUX were already quite mature. It was great to be able to share and learn from other leaders in the field. Although I've presented at several conferences since this one will always be special. I'm sure thatJeff, Anders, Eewei, Darci and Jeremy will agree that theunofficial luminaries party and crazy impromptu road-trips to rediscover the origins of the manifesto will be hard to forget!

BA2011 was great fun. I have always considered myself a poly-skilled person who can float between the overlapping worlds of UX and BA. Now more than ever I realise that these disciplines are very similar indeed. The main difference I have observed is the subtle but powerful shift in a UX mindset that puts the end-user at the heart of every decision. (The other difference I observed is that BAs tend to dress smarter that their colleagues in experience design! ;-P )

Here are some nifty mindmaps that Penny Pulman (who also did a great session on visual thinking) created from my session:

In a previous life I used to lead a NewMedia Team for Cambridge Assessment so speaking at this Cambridge based event allows me to visit old friends and make new ones. I also participated in the closing panel on AgileUX for this conference.

When ThoughtWorks opened its Hamburg office it was keen to kickstart an Experience Design Community there. As Experience Design Practice Lead for ThoughtWorks Europe I was asked to present to Hamburg's longstanding UX community. We were delighted to host a meeting of the Hamburg UX RoundTable in the newly opened office. Attended by about 100 practitioners this was an amazing way to meet the local talent first hand. Happy to report that the ideas seemed to strike a chord.

They even made a nice podcast of the talk