Mapping is all about situational awareness and understanding the context of a complex system whether an organisation, a line of business or a technical system. Without good situational awareness then it’s extremely difficult to identify where to attack and hence strategic why (since ‘why’ is a relative statement – why here over there). It’s even difficult to know how to manage something – Simon Wardley
On the technical side of software development we have many useful maps that we use to understand our work. Among these are architecture diagrams, object diagrams and domain models. But what about the maps we use on the business side? The maps which should help to us to ensure we are building the right product?
At a recent conference, a common theme touched on by many different speakers was to focus on The Why of the product. What user needs are being addressed? What problems are we solving for the user? It struck me that many people are working on projects where they do not know The Why. They feel that they don’t have a situational awareness of what the product is. Given that the main purpose of a good map is to faciliate situational awareness, I wondered whether the maps we are using are deficient.
Our primary “map” these days is the card wall. Card walls are everywhere. There are card walls for each delivery team, cards walls of card walls (SAFe), card walls in HR departments, card walls in kitchens and garages etc etc. Card walls are fine for short term tracking of tasks to be completed. They work well to faciliate communication within teams around work that is underway. But cards walls do not give an overview of our work.
Original agile teams used to tear up cards as soon as they were done. Nowadays we normally leave them in the Done column until the end of the iteration. Then they are removed never to be seen again.
For upcoming work we organise the card backlog in terms of priorities for delivery. A backlog is just an ordered list of cards. You can’t look at a backlog and see connections between cards or to the overall context of the work. You can’t look at a backlog and get a meaningful understanding of how much work is left.
Card walls don’t provide (and are not designed to provide) a map of what has been delivered or what will be delivered. The card wall’s focus is on what is happening now. It does not represent the work we have done or the work that is coming up in a meaningful manner.
The closet thing I’ve seen to a usable map is the User Story Map developed by Jeff Patton. This categorises storoes into abstract functions (eg. ordering, paying, invoicing). It also demarcates releases which helps to provide the temporal context for cards. However, the User Story Map is ultimately just an ordered list of cards. There is no easy way to navigate through a User Story Map. You have to read the cards and draw the connections yourself.
In this post I want to outline a new kind of map that addresses some of these shortcomings. I call it a User Value Tree.
Constructing a User Value Tree
What we need from a map is situational awareness. Some properties of a good map include:-
- The ability to see the whole terrain
- The ability to see individual elements within the terrain
- The ability to group like elements
- Representing connections between elements and groups of elements
- The ability to represent change in the terrain over time (where relevant)
- The ability to easily visualise alternative paths through the terrain or alternative states of the terrain
To know that we are building the right product we need to understand the needs of potential users. We want to know the motivations of the users and what tasks they are trying to accomplish. We want to know that the system is useful.
Traditionally we have User Stories to represent the individual tasks or goals of the user eg. I want to pay for my shopping cart; I want to organise shipping etc. What has been lacking is a way to meaningfully group individual user stories and relate them higher level users needs and values (although User Story Maps do this to some extent). That is where the User Value Tree comes into play.
Let’s walk through the construction of a User Value Tree.
We begin at the top with the user’s role and a high level description of what their overall values or goals are. In this case, we have an Account Manager at a consultancy. Their role is to keep clients happy by ensuring that the product is built and delivered to the client in a timely fashion. Note that you could enter more detailed, user persona-style data in this place. [Note: zoom in or open the image to view it properly]
[Note: zoom in or open the image to view it properly]
Next we describe the high level, abstract tasks that the Account Manager carries out in their role. Account Managers work on a project-by-project basis even if the client is the same.
The first step is to get an initial project scope which is a high level description of the job. This involves ascertaining if there is a basic fit between what the customer wants and what the consultancy can provide. Do we have the right technical skills to build the product? Do we have enough manpower? Can we meet the timeframe? etc.
If this step goes well, we move on to negotiate terms of service. This is a more detailed breakdown of the work. Which consultants will be involved. What they cost. How long they will work on the project etc.
The next step is the signing of formal Statements of Work, contracts, non disclosure agreements and the like. Following that the project gets underway and the AM’s role is to stay in contact with the client to ensure they are happy with progress.
We can see that the User Value Tree has parent and child nodes. The parent nodes represent the value that is delivered when the child nodes are fulfilled. In the case of the AM at the consultancy, the customer is only happy when the product is only delivered. In order to deliver the product, we have to carry out the four child nodes. The child nodes therefore represent an entire flow of work. The horizontal grouping of nodes represents this relationship between the tasks. We capture it by having the child nodes connect upwards to a single horizontal line which then links back to the parent. This means that the tasks below are in an ordered relation. They must be carried out in a fixed order.
If you start at a child node and ask the question “why is this task important?” you simply navigate up to the parent node to find the answer. Why do we conduct initial product scope? Because it is part of delivering a product to our client. We can’t deliver a product without first knowing what the product idea is. Similarly, we sign contracts and statement of work because they are legal requirements that must be in place beore work starts.
This ability to capture the parent-child and sibling relationships between tasks is a key feature of the User Value Tree.
To continue constructing the UVT, we take each node and ask the question “what child tasks are needed to complete this task”? In this example, we focus on only two nodes.
“Negotiate terms of service” requires creating a detailed forecast of labour and costs and then communicating it to the potential client.
“Liaising with the client throughout the project” involves managing expectations around budget, labour and scope. This is because projects start with the forecast of labour and costs but things happen are not in the forecast eg. sick leave, resignations, unexpected events. There is a constant process of ensuring expectations are updated to meet reality.
Note the difference in how the child nodes of the “Liaise” task are connected to their parent. In this case, there is no horiztonal connection between the children. What this means is that there is no necessary relationship between these tasks in the real world. You do not have to manage budget expectations before managing labour expectations. You can manage scope without worrying about time and money. We represent this by drawing a single line from each child back to the parent. This is different from the parent-child relationship at the top level where each child was horizontally connected to each other before joining back to the parent.
This ability to represent whether tasks are necessarily connected or not becomes useful when prioritising work and thinking about releases of the software.
Finally we get to the last level of the UVT. This level represents the User Stories we need to build our system (you could think of the higher level taks as Epics). The child nodes of the “Create forecast of labour and costs” are Create a Project, Create a Forecast and Export a Forecast. As the child nodes are connected to each other horizontally, we know that they are in a dependent relationship. In order to create a forecast, we must first create a project. In order to export we must first have a project and a forecast. We also know that all three of these tasks must be carried out before we have delivered the higher level value of creating a forecast of labour and costs.
For liaising with the client, the system only provides functionality around budget expectations. It measures the discrepancy between expected and actual costs.
At this point we have the full User Value Tree for this project. The Parent-Child relationship at each level allows us to easily navigate through the tree. You can go to any user story and ask the question “why is this important?” The answer is already there in the parent node.
Why is it important to create a project? Because you need it to forecast labour and costs.
Why is it important to forecast labour and costs? Because it’s part of negotiating terms of service with the client.
Why do you need to negotiate terms of service? Because you need to give a price estimate and agree on how work will be carried out.
Thus, the User Value tree gives us a clear and detailed situational awareness of the user’s goals and tasks.
The User Value Tree as a map
We can see that the UVT fulfills the properties of a good map:-
- It provides an overview of the whole terrain. In this case, the tasks and needs of the Account Manager.
- It places individual elements in the terrain i.e. the tasks.
- It groups the tasks meaningfully showing which tasks are connected, which tasks need to precede others, which groups of tasks add up to higher level goals.
- It allows us to visualise different pathways or alternative ways to do things. For example, what if we removed an entire branch or work, could we change the order of branches of work, what if we did not provide certain tasks or branches of work in the software, could these be handled manually?
For any given task, the UVT allows you to place it in its context – the parent goals it contributes to, the child tasks needed for its fulfilment, the tasks that precede it and those that follow it.
The fractal structure of the UVT also allows you to drill down to as much resolution as you would like. In the example above, we stop at the level of the User Story as this most relevant for us in software develoment. But there is no restriction on going to higher resolution and including lower level tasks. How do you create a project? You click on the Create button, you enter the name, you click save etc etc.
Conclusion
The User Value Tree is a map that gives us situational awareness of the user’s values, needs and actions. More importantly for software development, it gives us a way to place User Stories in their proper context: the value to the user. This enables us to see the relations between stories and how stories fit into the large picture of what we are delivering.
In Part 2 of this blog post, I will give an account of the UVT in action. We will see how the UVT can be used as a tool for discovering and specifying requirements, organising and track the daily work of the team (instead of the traditional card wall), planning releases, mapping test coverage and as a schematic version of a user persona.