[This is part two of this blog series. Part One contains an explanation of User Value Trees. You will probably need to read that to make sense of this post.]
We saw in part one that User Value Trees (UVTs) are a way to map the domain of a user’s tasks, goals and motivations. UVTs provide a way to connect User Stories to higher level goals and to group user stories into the flows of work that are necessary to achieve those goals. In this and the following posts I outline some potential applications for a User Value Tree based on my experience putting them into action. We start with User Value Tree as card wall.
User Value Tree as Card Wall
In part one of this blog post I noted that the (kanban) card walls that have become universal in agile software development are not maps. The card wall is a workflow tool designed to enable teams to visualise and track the completion of tasks.
This leads to a number of problems that I will explain in more detail in a future post. Among these is a lack of strategic visibility available to team members. As the vast majority of software projects revolve around delivering functionality to end users, it makes sense to track progress aganst the delivery of that functionality. This was the original thinking behind the advent of the User Story. The problem with the traditional card wall is that it focuses on the workflow of the team right now. Who is doing what? What is the status of the stories? What is the priority of upcoming work? Cards arrive onto the wall and disappear off the wall. The focus is always the current iteration. This makes it very easy to lose sight of the bigger picture. Almost all agile software development projects struggle with this challenge.
I wondered what would happen if we used a User Value Tree instead of the usual kanban card wall to track the team’s work. Would this change the focus from the low level implementation details of the project back to the user value being delievered?
Because User Value Trees include User Stories, this turned out to be quite a straightforward adaptation. We attach avatars, status stickers and mark stories as Done in the same way we would on a normal card wall. This is what it looks like (zoom in for greater clarity):-
This is the same UVT presented in part one of this blog post. We turn it into a card wall by annotating the user stories with the usual markings. The avatars indicate who is working on which stories. The green ticks indicate stories that are done. The red stickers indicate stories that are blocked. Because the User Value Tree contains all the stories we currently know for the project, it also functions as a backlog of work.
We can do everything on this wall that we can do on the normal card wall. However, this wall contains important information that is not captured on traditional walls:-
- We currently have a dev pair working on the “Export a Plan/Forecast” story. We see that when it is done, we have delivered the complete work flow which will enable the Account Manager to create a forecast of labour and costs.
- As the “Send to potential client” card is already done, once the create forecast work is complete the higher level goal of negotiating terms of service is also done. The Account Manager should be able to use the system for that purpose shortly.
- There are no User Stories below the “Manage labour expectations” and “Manage scope” tasks. Have we been unable to do the analysis on this work? Why not? This is a risk.
- A large part of the Liaise with Client work is blocked. This is a risk.
- We know from the structure of the UVT that delivering the “Measure discrepancy between expected and actual cost” card is of value in liaising with clients. This task can be completed independently of managing labour and scope. We know that delivering that functionality on its own will be useful to the Account Manager.
- When the “Export a Plan/Forecast” card is done we don’t have any more user stories ready to go. We should start to discuss what to do with the dev pair when that happens.
Note that all this information is represented visually. As the team gathers around the wall for standup each morning, the UVT tells us the status of the project. We still see the work that is in progress. We also see how much work has been completed. The status of individual stories is placed within the context of the whole body of work. We get the status of the whole project.
There are some other important properties of this kind of card wall:-
- There is an implied theme of work built-in. Currently we have have two user stories in play. These correspond to the larger themes of “Negotiate Terms of Service” and “Liaise with Client”. On scrum teams, this should be a visual representation of the current iteration’s theme. On non-scrum teams, this solves the persistent problem of losing focus on the goal of the current work.
- There are natural release points built-in. Once the Export story is done, we should be able to release all the Negotiate Terms of Service functionality. This is relevant for teams not doing continuous deployment.
- For teams that want to break down user stories into tasks and put them on the wall (even though I think that’s a bad idea) they are easily placed below the user stories.
- We represent workflow by the avatar/status marker that is on the card. A card with a BA’s avatar is “in analysis”. If a dev pair’s avatar is there, the card is “in dev”. If a tester, it is “in test”. The green tick is “done”.
- Larger teams will almost certainly be working across multiple User Value Trees (one UVT for each user). Thus, the User Value Tree concept scales quite easily. If the teams are working on the same User Value Tree, it is easy to visualise how the work of the teams contributes to the larger delivery plan.
Using the User Value tree as a card wall is quite a shift in mindset. Gone is the card wall which focuses only on the current iteration of work. Gone are the columns which track the status of cards. These are replaced by focusing on the larger meaning of the work – value delivered to the user. We conduct standup each morning in front of the entire functional scope of the project structured as a User Value Tree.
We still track the status of cards and who is working on what. But we do so while placing the card in the context of value delivered to the user. We can see how the current stories that are being worked on contribute to the larger system. We visualse both the work that has been completed and how much is left to go. And every morning at standup we are reminded who the user is and what their goals are.
I believe this shift of focus is a very beneficial one. Modern software development teams are too preoccupied with their own internal workflow and not on the value delivered to the user. Kanban card walls reinforce this mindset.
The User Value Tree brings the team’s focus back towards situational awareness of the whole project. This should improve the ability of teams to think strategically and steer projects towards delivering value to the user.