Visualizing Work

Work can be hard enough, it doesn’t need to be invisible!

NOTE: Please fill out the “contact us” form on the right, or just leave a comment asking, if you’d like to be notified when the future webinar series on this topic is scheduled.

Here is a selection of visualizations that I find very helpful when managing work, either my own work or an organization’s work with 22 teams.


Roadmap connect multiple high-level threads together over many quarters or years. They answer the questions of Who, When, How Often, What, Why, and How. Some can be sparse and others very (over) loaded. Here is a quarter of a year long roadmap that shows the various connected teams and how their work is connected:

Multi-Level Roadmap with connected work

This roadmap exposes the actual complexity of the current work management system.

Program Management

A program is a work managed towards a specific goal. Programs are larger than any one team and take longer than any near-term planning horizon. Here is a small visualization of a program from an unreleased tool. Work is pulled from the right, always completing towards the valuable goal on the left.

Screen Shot 2013-04-23 at 4.26.34 PM

A program of work is more structured than just a list of items, as an Agile backlog often is. Often, a program makes an excellent wrapper around the bulk of the agile backlog. programs tend to important integration milestones and reviews that provide a natural tightening shape.

Agile Release (Quarterly) Plans

Agile “release” planning covers the scope of multiple sprints. I usually suggest quarterly planning but this could be anything from one to six months. This planning does need to include multiple sprint ahead, in order to gain the benefit of coordinating dependencies across teams (or dependencies will become unplanned interruptions).

First, we see a multi-team release plan based on sequential dependencies. Here a project or program named “A” is works on by several teams.



This sequential style of work management has the disadvantages that the plan must be “right” and any delays can cause havoc at the end of the timeframe.

Next, we see a multi-team collaborative model for work management. In this case teams are working directly together at various times to collaborate on the work.


Notice in this more collaborative style that there are fewer elements to manage. This is actually a simpler way to manage work, but the actual collaborative activity will be highly messy and fast-paced.

Personal and Team Work

Visual Boards have long been useful for individual and team work. Here is the simplest example, showing Ready-InProgress-Done designations for work.

Tempest - Kanban2

Here is another example, with both more states for work to move through (columns) and more specific routes that work can travel (rows).

Kanban UX in Pod 2

These more details work management boards have two key values:

  1. They show what is actually happening now
  2. They indicate what you should do next

Something these boards don’t do well is provide the connection to the big picture. There are some variations on these (called 2-tier kanban boards) that show one level up, but this doesn’t give enough visibility when we are working on a single activity for a program or roadmap level goal.

Common Abstractions

All of these visualizations have a few things in common.

  • They use space and structure, and sometimes lines, to indicate meaning and relationships
  • They have a direction, work is either approach from left (time) or right (priority)

Ignore hours, focus on collaboration

Here’s a quiz for Agile team members using burndown charts.

What does this picture mean?

Seems pretty good, right? Work is getting done, pretty close to the ideal line. Nothing to fret over, especially if the mood of the team is good.

Now, consider this alternate view of the same team, same sprint:

We’re about to start the eighth day of a ten day sprint… now it looks like panic. At least a few story points are done-done… but clearly the team hasn’t actually finished much of the work in the sprint. Will it all get done? Will it all get done? Are we looking at a mini-death march?

How could there be such a mismatch, and what can we do about it?!?

Advice: Ignore hours

A team I was coaching was really struggling to complete stories at the end of the sprint. They were being very diligent, but no matter “hard” they tried it didn’t change the emergency they experienced at the end of every sprint. In particular, they tried harder to get better at estimating task hours and making sure to level everyone’s hours….

I became clued into all of this when I was asked: “John, do you think 6 hours per day is reasonable?” This was a sure indicator that the team was missing the forrest for the trees – loading individuals with tasks/hours at the expense of a team getting work done. This was setting each individual up for failure: either I can help my colleague/friend… or I work on what I committed to doing! I don’t like no win situations, especially when it hurts people.

My advice was simple. Just for one sprint, try the following:

  • ignore hours, don’t estimate or track then
  • focus on the stories, which one is highest priority
  • encourage the team to work together in every way that makes sense
  • track story point burn down

The team did this, and the result was amazing. Everyone felt free to collaborate and the stories were completed more smoothly. This team did reintroduce some hours back into their process, but they had changed: collaboration and value over hours and tasks.

Note on Kanban: As an interesting note, today most Kanban teams don’t bother with hours, and also don’t estimate stories! (They do often group by size.. so there is still some judgement of effort.) These teams track only cycle time (from start to end) of stories on the board. This gives the same focus on collaboration over hours tracking that I suggest in this post.

John Heintz co-presenting at Agile Roots 2010

John Heintz will be co-presenting with Israel Gat on Toxic Code.

I’m very excited, both to be presenting with Israel Gat (The Agile Executive) and to be going to Agile Roots this year!

We’ll be presenting on Toxic Code. This is a topic that I spent a lot of time on last year, working with a client to re-architect a system from the inside out while it was running in production.

Here’s the abstract of the session:

Technical debt had originally been conceived as an expediency measure – “a little debt speeds development so long as it is paid back promptly with a rewrite.” However, like financial debt, unrestrained borrowing can lead to a broad spectrum of difficulties, from collapsed roadmaps to inability to respond to customer problems in a timely manner, and anything in between.

Recent advances in source code analysis enable us to quantify technical debt and express it in $$ terms. By so doing, the software development process can be governed with unprecedented effectiveness. It is possible to constrain the “development on margin” mal-practice and avoid the toxic code phenomenon: technical-debt-to-value ratio of 100%. Moreover, even toxic code can ultimately be “marked-to-market” by reducing/eliminating technical debt.

The combination of Agile refactoring practices with technical debt analytics brings rigor to the software development process through:

  • Providing quantifiable data about the overall state of the code and its value
  • Driving the refactoring carried out through the Agile process from a risk mitigation perspective
  • Balancing the technical debt work stream vis-a-vis other work streams

In the course of managing software development in this manner, your team will improve its design, coding, testing and project management skills. Ultimately, these improvements are the best antidote against accrual of technical debt in the future.