Feature Injection, Fidelity and Story Mapping

I’ve recently stumbled into a way of describing mid-range planning with a few teams which combines the language of feature injection, fidelity and story-mapping. As it seems to have been a successful way of communicating how to think about the strategic approach to incrementing and iterating through the work, I thought it would be worth writing down. Before I get into the combination, first an overview of what I mean my feature injection, fidelity and story-mapping.

Feature Injection

Liz Keogh has written a nice summary of Feature Injection. The main take-away is the language around starting with high level needs before working down to low level solutions.

Vision > Goals > Capabilities > Features > Scenarios > Stories

The key levels that I find valuable are those of capabilities and features leading scenarios and stories. I have noticed that I swap scenarios and stories around compared to Liz. I tend to think of scenarios as being detailed examples of stories rather than stories being the detailed description of scenarios. Something to talk to Liz about next time I see her. Either way, the approach is to start with a high level, more impact-based understanding, and gradually inject more granularity until you get to the actual output you want.

Fidelity

I first wrote about fidelity a couple of years back. I draw it differently now so here’s an updated description.

We regularly refer to vertical-slicing with agile approaches, where the vertical-slices are functional pieces which cut through the horizontal architectural layers.

photo 1

I find that teams who use vertical slicing, still often tend to increment the vertical slices so that they risk ending up with a product which is built up of vertical slices, yet still only 90% complete.

photo 2

One way I describe avoiding this is to make each slice thinner, and spread the slices across the overall scope before going back an filling in the gaps. Each thinner slices is a low-fidelity slice, and filling in the gaps increases the fidelity.

photo 3

Another way is to think of it, using a similar 3-d approach to my original post, is for the depth dimension to represent fidelity. Thus the first pass across the vertical-slices is a very shallow-fidelity one, and further passes increase the depth of the fidelity axis.

photo 4

Given that we are now slicing across the depth dimension, and depth gives us perspective, I’m thinking of calling this “perspective slicing”. Each slice gives a different perspective of the whole system.

I’ve also found the term fidelity useful just from a conversational aspect. Simple discussing what fidelity means for a particular product or service, and how it is different from quality, raises some good awareness of the approach. In particular, that a low-fidelity solution (e.g. one which has a basic interface or low robustness) can and should be high-quality (e.g. have a clean design and be sufficiently tested).

Story Mapping

Jeff Patton best describes the technique he calls story mapping in his own article. Essentially its a way of adding more context to a backlog by visualising both the breakdown of work from large user activities down to small user sub-tasks and task details, the relative necessity of those sub-tasks and details, and the overall relationships between the large user activities. The story map is used to focus on starting to build an early walking skeleton of the whole product or system.

Combining the Ideas

The combination of feature injection, fidelity and story mapping ideas isn’t really anything ground-breaking, or spectacularly new. In fact Jeff Patton’s description of what he calls a release readiness assessment is very similar. The way I do it is to use the feature injection language of capabilities and features to describe the higher levels of the story-map, replacing what Jeff describes as activities and tasks. Jeff’s sub-tasks or task details then become stories or scenarios and they are ordered by increasing fidelity rather than necessity. Thus the walking skeleton is a low fidelity perspective slice across all the capabilities and features of the solution. Further iterations increase the fidelity with further perspective slices.

photo

Let me know what you have done which is similar or different!

Trains, Shopping and the Risk of Release Dates

I was recently on a Q&A panel and fielded a question about how to deal with fixed date and scope projects. My response has evolved into a blog post which has just been published on the Rally Coaching Blog. Take a look and find out what the question has to do with trains and shopping!

Fidelity – The Lost Dimension of the Iron Triangle

One the topics that I find a lot of people find particularly interesting and useful is that of Fidelity in software. This generally comes up while I’m talking about incrementing and iterating, and the difference between the two. I’ve already touched on this when discussed whether a Kanban System eschews iteration. This post will build on that, and describe what I mean by Fidelity.

The Iron Triangle of Project Management is a well known concept. There are a number of basic variables to project delivery; scope, cost and time. Not all these variable can be fixed, and generally quality is in the middle as another non negotiable variable.

Triangle

This can be related to a typical Agile Burndown, in that the Horizontal Axis is Time, the Vertical Axis is Scope, and the burndown slope is a function of cost and time. Keith Braithwaite and Joseph Pelrine both blogged about this after a conversation we had in Zurich earlier this year. I like to add a 3rd variable into that function that determines the slope – fidelity.

Burndown

Fidelity is similar to concepts I picked up from a number of places. One is Dimensional Planning where a number of different solutions are planned, each with a different level usability. A Dirt Road solution is the most basic, a Cobble Road solution is intermediate, and a Tarmac Road solution is the best.

Dimensional

Another source is Jeff Patton’s work, and in particular his approach to grading features. Similar to school or college work, each feature can be graded from A to F, where A is the best solution, and F is the least acceptable. Understanding how our customers perceive features in these terms, along with what the minimum acceptable grade is, helps with knowing when to continue working (and maybe come back later) or when to stop and move onto another feature. My colleague Simon Bennett refers to this a Balanced Scorecard technique.

Grades

So fidelity refers to the finesse of the feature, or solution. A low fidelity solution will be low in things like precision, granularity, or usability, but will still solve the original problem. As fidelity increases, so does the precision, granularity, usability etc. I prefer to make a distinction between fidelity and quality to avoid getting into discussions about compromising on quality. One recent project I was involved with talked about fidelity in terms of Rich, Richer and Richest.

Fidelity, as I have described above, can be useful when understanding the difference between incrementing and iterating, and how they can be effectively combined. We can consider 4 distinct approaches; Big Bang, Incremental, Iterative and Agile.

Big Bang

A Big Bang approach is neither iterative or incremental. Architectural components are built to full fidelity, for the full scope, and are fully integrated once at the end.

Big Bang 1

Big Bang 2

Big Bang 3

Incremental

The purely incremental approach builds each feature, across all components, to full fidelity, one by one.

Incremental 1

Incremental 2

Incremental 3

Incremental 4

Iterative

The purely iterative approach builds all the features, across all components, to the lowest fidelity, and then increases the fidelity to the highest level.

Iterative 1

Iterative 2

Iterative 3

Agile

An Agile approach combines the incremental and iterative approach by building each feature, one by one, at a low fidelity, and then both gradually adding features and increasing their fidelity until the right combination is achieved. Full fidelity is not always necessary.

Agile 1

Agile 2

Agile 3

Agile 4

Agile 5

Agile 6

It is by adding the Fidelity dimension into the mix that Agile projects can achieve the flexibility required to deal with typical scenarios where scope, cost and time become fixed, without resorting to cutting on quality. Fidelity provides a mechanism to effectively vary scope, while still meeting all the customers needs and solving their problems.