We finally implemented a Kanban board here at team Astrid. Kanban is a Japanese word meaning “billboard”, and describes a process invented by Toyota for tracking manufacturing process by moving cards around. The agile software engineering movement has (relatively recently) co-opted the terminology and idea of Kanban for managing the software construction process, sometimes to great effect, and sometimes to great sadness.

Jon and I had been reluctant to go Kanban for the following reasons:

1. not online, sad for offsite workers and working from home
2. doesn’t replace traditional bug-trackers
3. will we have the discipline to manage an additional process?

However, once we saw an example of a Kanban board done well, we were both convinced. So, dear readers, let me show you our modern-day interpretation of the “Kanban Board For (Small) Software Startups ™”, and maybe you too will be convinced. We think it encodes a lot of good practices from the lean startup/agile/lean ux schools of thought as basically forces us to test and learn at each step.

(our board)

Our cards are color-coded by product (green = web, pink = android, blue = ios), and we have yellow-stickies with the names of our team members, indicating what they are working on. Cards are either not on the board (icebox / victory), in a lane, or in-between lanes, indicating that they have been pushed and are awaiting acceptance into the next lane. I’ll discuss what this means for each section.

---

Overview

At a high level, the board starts with problem statements. They can be customer problems (“search is really slow”), business problems (“users should be able to pay for support”), or engineering problems (“logging framework”). These problems are prioritized, and then the design team works on the specifications and wireframes. When that’s ready, engineering builds and delivers to test. Accepted engineering stories go live, where they are measured for effectiveness. Finally, as time passes, our team circles back on stories undergoing measurement for learning purposes.

(process flowchart on a napkin)

Icebox

Although it’s not one of our columns, the big board starts with the icebox:

Our icebox is basically a pile of cards that anyone on our team can add stuff to. In addition, we collect user feedback from our support sources into a “top requested features” list.

Plan

We take icebox cards and put them on the roadmap, ordering cards by importance from top to bottom. There’s no “delivery” process for the planning column – instead, the design team pulls cards from the top when they are finished with what they are currently working on. In addition to monthly prioritization meetings where our team collectively votes on new directions to pursue, the PM will rearrange cards on a weekly basis to reflect pressing new concerns, or (more likely) move cards up to fill the void when cards are pulled. Our twist on planning is that we assign each card a “design budget” – a time limit such as 1hr, 3hrs, 6hrs. There is no room for perfect design in a startup, and so we define a scope for every project.

Design

In the design phase, our design team (founders, graphic designers, UX, PM):

• comes up with ideas for how to address the problem statement (founders/PM)
• creates UI wireframes (GFX/UX/PM)
• tests and iterates wireframes via hallway testing, user interviews, facebook surveys
• creates high-fidelity wireframes (GFX)
• comes up with rough spec for the engineering team
• decide how to measure success (metrics)

Our rule of thumb is for each 5 hours of engineering time, we spend 1/2 hour performing validation. At the end of the design process (or when the hourly budget is reached), the card is “delivered” to the engineering team, who check to make sure that the proper validation has been performed (is there evidence that this design works?). Specs can be rough because it’s understood that the design will iterate as the engineers work on the project, but the specs have to exist in some form so engineers know what they’re building.

Want to see an example of a cheap and effective validation? Boom. Four options, 10 minutes, 10+ opinions. It’s not perfect, but it doesn’t need to be.

Build

The heart, guts, and core of your company.

…

When the engineering team delivers a feature, QA has to test and accept it before it can be moved further. We have a special section on the Build/Measure divider for untested and tested features:

Measure, Learn, Goals, and further thoughts

… Stay tuned for part 2!