How Digital Agile Management Tools Make You Blind (And How A Physical Kanban Board Can Help You See Again)

Creative Commons License flik

We’ve been using PivotalTracker for years to manage our agile software development process. It works like a charm for us. Whenever an idea comes up, we enter it into Tracker as an Epic (no matter how rough and abstract it might be). When the time comes to start implementing it, we usually break it down into more detailed User Stories. As soon as we’ve covered everything with User Stories, we delete the Epic. We just make sure that all stories derived from that Epic have a common tag to make sure we know where they came from.

The Pain Of Missing The Big Picture

But, we don’t track non-coding chores in PivotalTracker. Tasks like graphical design, documentation, doing client proposals or the like are not tracked at all. This leads to a blind spot in our shared perception of how the work is going. In fact, PivotalTracker is only a spotlight highlighting the coding work whereas everything else stays in the dark. This became an issue over time as we lacked shared awareness of what everyone else was doing.

Another problem with this approach is losing the overview about which Epics we’re currently working on and how close we are to finishing them. Of course, we can look at our backlog and see which stories having the Epic’s label are in which state, but this is tedious. It’s definitely not obvious for anyone interested in the progress toward our overall goals.

Gaining Visibility By Combining A Physical Kanban Board With PivotalTracker

To address the issues we had with visibility and overview, we introduced a physical Kanban board. We write the Epics and all non-coding work onto cards and stick them on our Kanban wall. There we currently have six columns: Backlog, Planned this week, In Progress, Testing, Ready, Done. We move the Kanban cards through those stages (usually we move them during our daily stand-up meeting). For an Epic, which has a lot of stories in PivotalTracker, we move the card to “In Progress” as soon as the first story gets started and we move it to “Testing” as soon as all stories are ready to test. When all stories are tested but not released yet, we move the card to “Ready”. Only after the release we move the card to “Done”. Non-coding tasks get their own cards. That way everyone in the room (and anyone walking by) can see at a glance what the whole team is working on.

Combining a physical Kanban board with our online tools really boosted visibility and overview. It helps us focus on the stories belonging to a certain Epic and shows us who’s working on what. That way we’re able to make sure the whole team is working on the most important things at any time.

4 thoughts on “How Digital Agile Management Tools Make You Blind (And How A Physical Kanban Board Can Help You See Again)

  1. Mathias,

    Interesting post on linking the big picture. We use two kanban boards. An enterprise kanban that tracks epics and a team kanban that tracks stories. I had recently blogged about it here – http://bit.ly/hWVuhA and here – http://bit.ly/dXhgmp

    One question: In your system, you only start testing once all the stories are done. Doesn’t it make more sense to test stories as they get done?

    Like

  2. Siddharta, thanks for sharing your ideas about combining an enterprise kanban with a team kanban. I like this idea very much.

    In fact, we start testing (= verifying by product management) individual user stories as soon as they are marked “Delivered” in PivotalTracker. On the kanban, we just move the card when all stories are delivered but not all stories are tested yet. This situation happens if developers where faster in coding stories than our product managers in verifying them. Of course, all features are covered by unit and automated integration tests (done by the developers as part of coding the story).

    As soon as testing of all stories for the epic tracked on the kanban is done, we move the card to “Ready”.

    Like

  3. Why don’t you track non-coding “chores” like design and documentation in Pivotal Tracker? If they are important parts of software “delivery” (which is what we’re trying to accomplish, as opposed to “development”, which is just part of delivery), shouldn’t they be managed/tracked/executed as part of the same agile, integrated process and tool set?

    Like

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.