Sense of Purpose and Direction with Domain Storytelling and Impact Mapping

In one of my previous posts on Domain Storytelling I discussed introducing Impact Mapping as a workshop headliner to enable smoother workshop facilitation. This time we take a look on how to use both Domain Storytelling and Impact Mapping to sustainably manage your product backlog on a daily basis.

Teams working in a corporate environment and trying to work in an agile way often struggle with an ever growing list of features in their backlog. The rate of the features being finished is not as nearly as high as the rate of new features being added. After a while the big picture becomes hard to discern regardless of the way the backlog is structured.

If the sense of purpose in product development is important, then as a team we should be able to relatively easily explain why a particular feature is worth doing. If we struggle to answer this question then how do we know that we are building the right thing and providing value to the stakeholders?

Sense of Purpose and Direction

At this point you may disagree with me and claim that you are in full control of your backlog, able to remember or find every feature in there within seconds and quickly relate it to the business needs it was spawned from. Take a moment and ask yourself if that really is the case?

Perhaps the never-ending list of the features in the product backlog actually controls you, not the other way around.

Whenever I find myself reflecting over the product backlog I try to ask some basic questions regarding the sense of purpose and direction.

Purpose
Will the features in the backlog provide value to the stakeholders?
What is the goal we are trying to achieve by implementing each feature?

Direction
Are all the features in backlog aligned with the goal?
Are we moving towards the goal for each feature?
How do we know we are building the right thing?

Suggested Approach

Honestly answering these questions may open up some surprises as to the content of the backlog. In my experience, every product backlog I had a chance to study contained features that could safely be removed from there. More often than not this applied to most of the features in the backlog, actually only a handful would do in the format they were written.

In other words the features expressed in a great detail, almost as a recipe on what to do, have their place in the backlog only if they are in immediate danger of being consumed by the team, i.e. transformed to Work-In-Progress on your Scrum or Kanban board.

How then do we keep true to the purpose and make sure we head in the right direction?

This is where a powerful combo of Domain Storytelling and Impact Mapping come into play.

Domain Storytelling as a multi-role collaborative exploratory technique builds mutual understanding between the stakeholders and the team on what are the needs to be fulfilled, thus establishing the purpose of the development project. On the other hand Impact Mapping will challenge the team and the stakeholders to clearly define the goal and impacts the project is trying to achieve, and visualize the shortest path to get there.

In my experience, while communicating through Domain Stories is a great way to get both a big-picture and detailed overview of the stakeholders needs and intents, the documentation format of the stories is less suited to give the team a quick and authoritative overview on whether the project is heading to the right direction.

This is actually due to the very nature of Domain Stories, they excel when being focused on examples from the domain, and even more so when the examples are short and concise. This naturally leads to having multiple stories at the end of a Domain Storytelling session. What I have seen in successful teams that addresses the issue is a One-Pager that shows both the goal the team is trying to achieve and the current position in a landscape along the road. In other words a map.

Laying out an Impact Map helps documenting the goal and the direction towards it as well as verifying that you are moving towards the goal. Therefore, I suggest to consider using Impact Map as the primary tool for maintaining your product backlog on a coarse-grained level.

This translates to building an Impact Map during or in aftermath of the Domain Storytelling workshop (for some hints check out previously mentioned blogpost). This is by no means an easy exercise as it requires to dig deep to discover the patterns in presented Domain Stories that reveal the stakeholders’ real needs that could be translated to the business goals and impacts which form the backbone of an Impact Map.

I have on more than one occasion experienced that an iterative approach works well, revisiting the map, re-stating the goal into something that was more aligned to the recently acquired knowledge. This represents one of the core advantages of using Impact Map as the tool for defining the product backlog, it is easy to modify and adapt and keep in sync with what the team has learned. No expensive operations deleting the items or updating the links between the Features, Epics in some central storage. Everything resides on a single map with just enough details to provide ground for conversations around the product backlog with respect to achieving business value.

On the flip side, this means that we need to use multiple tools for maintaining the product backlog and we must somehow navigate between them. Simple links could suffice yet I acknowledge that this could be a challenge to implement in some environments. Another, more profound challenge using Impact Maps, is to specify concrete customer-relevant metrics on whether or not the impacts and the goal have been achieved. Actually I look at this as a good problem as it forces me to think in terms of measurable goals and impacts.

Wrapping Up

By all means, there is a great value in Jira-like tools out there, especially as they usually play a broader role in your corporate IT-landscape. They are actually quite useful when it comes to specifying fine-level backlog items and tasks. My recommendation is to use lightweight tools for coarse-grained items in your product backlog. Drawing both Domain Stories and Impact Map can be done in online tools or on Miro-board. The stories and the map are thus easily accessible and provide high-level overview in a very compact way.

Domain Stories and Impact Maps actually refrain us from providing detailed textual explanation at this level, which allows for greater uncertainty in planning, usually a good thing.

In my experience a visual Domain Story, linked from the Impact Map, provides enough context and detail to be able to make sound decisions about the road map and answer the questions of sense of purpose and direction in your product backlog at any time.

Curious about Domain-Driven Design, Domain Storytelling or Impact Mapping? Then check out this on-demand workshop of mine in collaboration with NDC Conferences.