A few years ago while waiting for a user group to start at the Manchester ThoughtWorks office I bothered a couple of the devs there about their board. That conversation, after a bit of fangling, led to my convincing the team I was on at the time to use a radar board to represent our backlog.

It allowed us to combine a fluid representation of the business's priorities with a physical representation of the cost of reorganising those priorities. But also, in a way you don't get with a columnar board, gave an immediate feedback mechanism when too much work had been proposed or accepted.

Apologies to the two ThoughtWorks devs if I misrepresent any of their good ideas as mine or my bad ideas as theirs.

The board was really simple. At the top right there was a small quarter circle labelled "now". Then a slightly larger one labelled "next". After that a slightly larger one labelled whatever you like to mean not-next-but-after-that. We experimented with a fourth quadrant but it covered ground so far away in time that it didn't add much distinction to the plan.

By chance I still have a photo I took as we drew an early version of the quadrants on the board.

You can see it's very straight-forward.

The radar board had the kanban board alongside it so you could see work getting closer to "now" until it was promoted onto the kanban board. We called it: radarban

Several points here:

• I am well known for my incredible artistic skills and ability at writing clearly. As this diagram shows.
• Bugs are a separate stream of work. You pull preferentially from that row running across the top of the board.
• The radar doesn't have to be huge. We had room for hand-recorded metrics alongside.
• The 'value' column is an obsession of mine. We didn't always have it. We didn't really get it to work. I think it's probably the most important thing most teams don't do.

What is it?!

Now

When there is capacity the team commits to work on something and moves it into 'Now'. For the team in question that's when we'd have the kick-off meeting and split it out into various tasks and stories (see below).

The quadrant represents in broad brushstrokes (what some would call 'epic' level) what the team is working on right, erm, now.

If someone has been out of the office they should be able to see at a glance what's happening.

Next

The 'Next' quadrant is whatever the business has prioritised to happen as soon as any current piece of work is signed off. Something getting into 'Next' is not a commitment to work on it.

Tracking cycle time let's you see when the tickets in Next should start.

Later / Maybe / Possibly / Probably

The third quadrant is weeks if not months out (all depends on your flow). And these tickets should be very vague because items here might never be worked on, or might change significantly before they start. If you're spending effort in this part of the board then something is wrong.

So far, so exactly like a backlog column, right?

What goes on it?

Everything goes on this board. Recruitment, holidays, business trips, when the new printer is arriving… (the list by virtue of being everything could keep going).

… …. Well, not everything, if nobody cares that a particular thing is on there stop putting it on.

Why a radar?

Physical feedback

The 'Now' quadrant is small. Those three tickets in the image above are pretty high-level and they're all that will fit in there. If somebody tried to add more work to that quadrant they'd have to overlap tickets, or crowd then together, turn them sideways… In other words they get immediate, visceral, physical feedback that they are overloading the team.

** So it would promote the conversation about the cost of a change to work in-flight or a higher load on the team. **

Expresses fluidity

It seemed that there was less mental barrier to reorganising proposed work when it was a set of concentric clouds of tickets than when it was a series of columns.

We had two. whole. whiteboards. of. backlog. at one point - guess how many people cared about the backlog when it was that big… In contrast it was a frequent sight to see the CEO and CTO stood by the radar reorganising the quadrants based on what had changed for them since it was last looked at.

Because there wasn't the implied (or explicit) priority of something being at the top of a column of tickets we avoided effort prioritising or discussing work until we were ready to move one or more of the tickets closer to 'now'. When we were ready to move a ticket we only moved whichever was best right now.

** So it would promote the conversation about what the priorities were. **

Not every idea is equal

Backlogs have a tendency to attract ideas that will never be worked on (for one reason or another). Limiting the amount of space for the backlog. And as a result limiting what can go in it forces you to maintain the backlog.

Keeping it incredibly low fidelity means people aren't invested in the idea as much and makes this process easier

** So it would promote the conversation about whether we need to or would ever work on an item **

It always works!

No, there are no golden bullets (or boards).

The context where I propose it helps is when business priorities are fluid, where they're not clear to everyone, or where the business doesn't feel the cost of changing work in-flight.

It's ok for needs and priorities to change but when they change frequently making sure everybody knows what is going on can be very difficult.

It's (sometimes) OK to drop everything because of emergencies or opportunities but it can also become the norm. It can be hard to notice that happening and to communicate the cost of that to the people asking for the changes. Walking over to the radar to say "we can move it in but we have to move something out" helps clarify this and let's everyone make a concrete decision.

Kick-off and split - as an aside

That 'kick-off and split' process was moving us towards a single-piece flow approach introduced to us by one of our colleagues Michael Dickens. There's an example here on Twitter where you can see in the centre the various tasks required to finish this piece of work stuck over a diagram of the moving pieces.

Or similarly described here by Kevin Rutherford where a diagram helps guide and frame the discussion of what work needs doing.

That should give you an idea of the scope of the tickets in now. Up to several pieces of work for several developers for several days.

At one point we did erase the kanban board, draw a complex process flow we needed to implement in its place, and stick post-its over that. It worked really well!

What do you absolutely need?

You need lots of space.

We had more than one whiteboard per person. So could afford three boards to describe our current and upcoming work. We were also colocated so we didn't need an electronic board (although we did have to have one and it was never up-to-date :/)

I've tried this recently with a different team. We have very little whiteboard space. We were trying to convey a lot of information in one place - it didn't work for everyone so we've moved away from it

It's a shame we couldn't make it work because even with a lack of space it was great for communicating what was coming towards the team, focussing on what we were working on, and promoting conversation about the things we were doing.

You need to talk to each other

Ultimately that's what this is about - if I haven't laboured that point enough.

This is a planning mechanism intended to force the right people to stand next to each other and agree about what is happening.

If you try this…

… I'd love to hear about it.

Tell me what worked and didn't, send me a picture, ask me questions.