Previously, in my article about Simple Planning for Startups, I talked about having a big board to track all the work. People have a hard time imagining this, so here, from my last startup, are some photos with explanations.
It’s important to note that this was what the board looked like on a particular day. It changed over time as we found different things important to represent. You definitely shouldn’t just copy this setup. Part of the reason we ran our entire company on index cards and painter’s tape was that we were continuously improving our process, and so needed flexible, easy-to-use tools to keep up.
Equally important: these cards were not requirements; they’d usually have just a few words each. Cards are just tokens representing converstations. A common novice mistake is to start adding details to the cards so that you can reduce future interactions. But the whole point of a process like this is to encourage collaboration and discussion. Keep the cards very simple.
Overview
Here’s the full board with the major sections labeled:
Green cards are hazily defined and sometimes quite large. Blue cards are ones that have been discussed and that developers believe are no more than a couple days’ work. Both colors represent shippable units of work described in business terms. There are also a few white cards that represent milestones like “open to 100 people”.
In general, cards flow from left to right.
Experiments
Here cards flowed from top to bottom and were separate from the rest of the board. The different pink labels mark different states in our experiment flow. This was an area that had more utililty early on, when we were wondering about relatively big questions. We also used it to track experiments that weren’t part of the normal development flow. But once we had a substantial product, the tracking of experiments shifted to discussion, because we all had become very experiment-oriented. Later still we built our own experiment-tracking tools to get good stats.
Deep Backlog
The deep backlog played little role in day-to-day planning. It was mainly an area for the product manager to think about the big picture. If we had actually implemented all of that, I’m sure it would have taken us a year or two. Of course, we were generating new ideas all the time, so many of those cards would have been obsolete long before we implemented them. But it was comforting to know that we’d keep our ideas around just in case.
Near Backlog
This was the focus of most planning effort. Let’s take a closer look:
The DO NEXT spot is the card that an available pair would pick up next. More accurately, they’d first check to see if another pair needed help, or if there was other work in process (WIP) that could take care of first. But barring that, they’d grab the next card. Following this rule strictly helped makes sure we all knew the whole code base well; otherwise it was tempting to pick things that seemed safe and easy.
The DO SOON area generally had a week or two of work. That wasn’t measured by anything more elaborate than breaking down cards until developers felt they were of a manageable size, which meant circa a day. (Blue cards were all of that sort.) Everything here was well understood by the whole team.
The next area down, DO AFTER THAT, contained the things that were close enough that we were thinking about and discussing them. Not all the details were nailed down, but since they weren’t going to happen right away, that was fine.
We also had an UNPRIORITIZED RECENT IDEAS area so that anybody (product, development, interns, visitors) could suggest something. Normally these cards would get prioritized and placed properly at the next weekly product meeting. This seems unusually full, which either means we were very creative or very focused on our existing plan.
In Play
This area represented work in process:
You’ll note that there are just three small columns here, all fixed in size to contain a maximum of three cards each. That’s intentional. It was very important to limit work in process (WIP). The more things you juggle, the more likely you are to drop some. Also, WIP limits help expose process problem. The columns wre:
WORKING, which was anything that was actively being developed. We kept a close eye on WIP here. Not just in terms of number of items, but also how long each item stayed in this column. It was our repeated painful experience that the longer a card lingered, the more likely there was a problem that we should discuss. A day or less was considered normal; two days was suspicious; three or more was dangerous.
ON HOLD was for items that had been started but couldn’t be finished. The most common reason for this was something where we were stuck on an external vendor or resource. (No contractors committed production code, but we did use outside experts for some research, visual design, and especialy tricky cross-browser CSS.) Having this many was unusual for us.
TO REVIEW once developers thought something was done, the product manager got a chance to do a final review before something was officially declared done. Typically it would have been seen a few times along the way, so this was just a final check, not a QA process.
The Past
FINISHED THIS WEEK was anything that had been completed during the calendar week. For the weekly retrospective we’d bring these cards over to our table, crack open beers, and talk about the good and the bad.
FINISHED BEFORE THAT was a month or so of completed work. We rarely looked at this, but there was an occasional question where it was handy to have it around. It was also nice to be reminded that we were making steady progress even though, as with every startup, it didn’t always feel that way.
Other Areas
Later on, we ended up with an area for developer-focused tasks on yellow cards. This was to keep track of things like possible refactorings, switching from one library to another, and cleaning up server operations. Developers shuffled these in as seemed necessary, always careful to maintain both a steady flow of user-visible improvements and a reasonably clean code base.
There are a number of stages that other people have that weren’t relevant for us. Some quick explanations as to why:
- Specification – Specification was replaced by discussion before and during construction. I now see product specification documents as waste to be eliminated by improving communication.
- Estimation – Other than the process where we took green cards, which were of unspecified size, and broke them down into blue cards, which were “not too big”, we didn’t do estimation. Because we were continually learning, our product plans were continuously improving. That means requirements were volatile enough that there was no point in numerical estimates for large chunks of work.
- Code review – Code review was unnecessary because we were a pair programming shop; everything was code reviewed all the time.
- QA – We were big fans of automated testing and site monitoring, so there wasn’t really a QA stage. I imagine that had the company lived long enough we might have added exploratory testers, but as it was we didn’t have enough in the way of bugs to justify that.
- Deployment – And after the first couple of months we set up a continuous deployment pipeline, so committed code was automatically deployed after 10 minutes or so of automated testing. A pair would typically commit every few hours and we almost never branched, so there was no need to track when something was in the short period between “done” and “released”.
Tips
This is what worked for us at a particular moment in time. If you’d like to try something similar, my strong advice is to start out representing what is actually going on with your team. Process is so ethereal that it’s easy to confuse what we want to happen with what people are actually doing. A big board like this should mainly express the latter. With that exposed, you can then start talking sensibly about changing the process in your weekly retrospectives. (Yes, you should be doing weekly retrospectives if you want ot make this work.)
As to physical construction, I normally start with large sheets of foamcore a hot glue gun, and some post-it notes. Just cut off 1-inch strips of foam core for the rails. Use hot glue to glue the rails on to a bigger sheet. (Glue toward the bottom instead of the middle so that there’s a nice little area for the cards to rest.) Then use post-it notes to label the sections.
I recommend starting with one color of index card, green or blue. (White are too easily mistaken for regular paper clutter; using the colored ones makes sure they look special.) It will be very tempting to immediately use card colors and marks and flags and other office supply joy to classify things six ways from Sunday. Resist that urge at least for the first few weeks. It turns out that units of work have many interesting dimensions, but few are worth the long-term sustained effort to visually represent them.
Credits
The layout was a collaborative effort, but the physical board was designed by Paul Howe. This version (we had different ones as we moved offices) was built by either Paul Howe or Cooper Dawson. If I recall rightly, it was built out of 1”x1” boards screwed to the walls. On top of those, we used double-sided tape and thin pieces of 1” trim board. If you’re just starting out, though, begin with the foamcore method described above; you can iterate with that much more easily as you figure out what works for your team.