Product organization

Article is considered a WIP. More plainly: the article doesn’t look done? Check back later; this stub is just here to remind me that I want to write about it.

Been thinking about product development organization/flow lately. Jotting down some related thoughts here.

Task organization

I prefer kanban-like workboards (i.e. columns representing state, items in the column representing tasks).

Note: Example Trello board illustrating this concept available here: https://trello.com/b/XtU6b4r6/master-board-example

Note: If using Trello, I highly recommend this extension which puts the tag label into the colored tag on cards.

Kanban columns

  1. BACKLOG
    • Stuff I wanna do.
  2. TO DO
    • Stuff I’m planning to do.
  3. ACTIVE DISCUSSION
    • Stuff that needs discussion (i.e. is probably “blocked”).
  4. IN PROGRESS
    • Stuff I’m doing.
  5. TESTING
    • Verifying the stuff I did sufficiently fulfills the task.
  6. READY TO SHIP
    • Work complete and tested locally, ready to deploy to the staging environment.
  7. SHIPPED TO STAGING
    • Work is available to view on the staging environment.
  8. FINAL REVIEW
    • Last chance to make changes.
    • Note: If changes need to be made, I’d probably make them as new cards and let the card in “final review” snooze until the change card(s) catch up.
  9. SHIPPED
    • Live on the web. High five!

Task order

Since kanban lets you order cards, try to take advantage of it. i.e. keep cards in the TO DO column ordered with “next task I’m planning to do” at the top and “last task I’m planning to do” at the bottom.

Tagging

I prefer to keep tagging pretty simple. The example board only has the following tags:

  • Design
  • Frontend
  • Backend
  • Bug
  • Growth
  • Project

“Project cards”

Project cards are ways of tracking a collection of related tasks (i.e. a project).

FAQ

What about due dates?

I believe work should be shipped when it’s ready to go (note: ready doesn’t mean “perfect”; “perfect” is the enemy of “good”). As such, I don’t usually favor adding due dates. Of course, that “only” works for ideal situations, not so much for reality – some tasks are time-sensitive. If a feature absolutely needs to hit a deadline, I’d probably set the due date on the larger “project card”.

What about multiple boards?

I believe multiple boards tends to add a lot of fuzziness to the bigger picture. By using a singular board with a sensible column flow, product developments on all fronts (design, technical, growth, etc) can be viewed in-parallel.

That being said, there’s probably good reasons to use multiple boards. For example, it might make sense for BACKLOG to become its own board, as BACKLOG items are “potential work” which kind of has its own flow (columns) with regards to becoming an actual workable TO DO ticket (i.e. discussion, research, task breakdown, etc).

What do I do about my 10-mile-long backlog?

The “attack plan” I’d consider:

  1. Ignore it. It’s mostly there to pull ideas from, you don’t really need to be viewing this list all the time.
  2. Prune it. Some of those old ideas you jotted down are probably crap, duplicated/completed, or otherwise irrelevant at this point.
  3. Handle it more extensively. For example, it might be a good idea to create a BACKLOG board (see “What about multiple boards?” FAQ), as “potential work” (backlog stuff) may have its own flow to become a formal “TO DO” card.

Ignore it, prune it, or create BACKLOG boards.

How do you feel about standups?

They seem like a waste if the Kanban board is well-organized. Consider these points:

  • A person should never have more than a few (3ish?) cards in their IN PROGRESS lane (indicating what they’re working on now).
  • A person should have a manageable amount of cards in the TO DO column indicating what they’re doing next.

ARTICLE UNFINISHED. COME BACK LATER.

Not covered yet:

  • code organization
  • wikis/documentation
  • larger specs (google docs?)
  • team communication (chats? standups?)
  • work hours