An agile project schedule? A rich visual backlog!

As you probably know if you’re reading this blog post, schedules, deadlines and agile are a bit of an oxymoron.

Recently, I’ve been assigned to lead a critical project with a very tight timeline. It requires more than 10 people from different groups in engineering, professional services and sales who don’t usually work together to join forces to achieve a common goal: wow the customer with our new product. In order to shine a light into everyone’s current activities, we started with a very simple Kanban board (next, working, review, done). But as the launch deadline approaches and I get more and more pressure from stakeholders outside of the team to have a more detailed project plan, I realized I needed more than a prioritized backlog.

The project manager wants a detailed schedule, with specific dates and milestones.
My main goal, however, is to figure out a good way to show progress in an easy and irrefutable way, so that the team always knows what lies ahead and whether we’re in track or not to implement what we need to be successful by the launch date. With the ultimate goal of being able to pivot as/when needed, of course.

So on my way back from AgileUXNYC (which by the way was awesome and I highly recommend it!), I was trying to figure out how to make a project schedule a living and breathing artifact that the whole team could interact with and use to both view and track progress.

And this is how I arrived at my visual project schedule, or rather rich visual backlog, namely a long piece of butcher paper taped on the wall containing:

  • Weekly milestones
  • Existing design and layout information
  • Stickies with user stories with due dates on them (which can be pulled directly from the schedule and into the Kanban board)
  • Non-functional requirements
  • Any high-level task that needs to be tracked and completed before launch

Visual project schedule

In the spirit of true agility, I could have done this directly on the idea wall, but since we are also working on a couple of other projects, butcher paper seemed like an ephemeral enough choice, and a more transportable one.

Since I had already done some user research, design and wireframing work prior to putting this visual project board together, I used that information to graphically show key design elements (such as page layouts) that need to be implemented for this project to succeed.

I designed it so that user stories that should result into a widget being implemented are written on a sticky placed where the widget will appear on the layout (w2, w4, w6 in the wireframe below).

Wireframe showing a simplified visual project schedule

Since user stories are also written directly on the butcher paper, when a widget placeholder has no sticky on the visual project board, it means it’s on the Kanban board and somebody is working on it (w3 above). After a story is done, we just add a¬†green check mark to the corresponding widget placeholder on the board (w1), done!

And this is how we can tell what’s going on with the project at a high level, in the context of everything else that needs to be done before launch.

Not surprisingly, the schedule ended up looking like a hybrid between a Story map and a Sketchboard, or biomap of the project. UX anyone?

I hung it on the wall that takes you to the kitchen area, so everyone in the office walks by it. This allows the team and other stakeholders to see a high-level project overview and status at first glance. The team can look at the board first thing in the morning, or when a story is done, and pick the next story directly from the current milestone. For the rest of the company, this is an effective information radiator. Anyone can tell what we have been up to, what we’re working on and what’s next, as well as when we’re planning to launch this critical project on a daily basis.

We’ll see how well it works over the next couple of weeks, but so far, the 30 minutes I spent creating the board have already paid off. Now the entire team has a shared understanding of scope and progress at all times, and everybody’s expectations are the same in terms of the work that we need to do before launch to define success for the customer.

Coincidentally (or not so coincidentally) these are two of my favorite quotes from Giff Constable’s closing AgileUXNYC talk:

“Be transparent, even if it hurts”

“Own results”

29. February 2012 by ariadna
Categories: Agile, Kanban, Project management, UX | Tags: , , , , | Leave a comment