We are constantly reviewing and modelling the way we organise who does what and when.

Currently, we have two basic ways to bundle tasks into manageable packages: Shapes and Ship-Its.

We started with one feature at a time, and evolved this quite a bit since then.


Stolen from the guys at Basecamp, we have set up our own way of describing problems along with a solution sketch, a team, and a time box. We deliberately took the parts that seemed useful to us from the original Basecamp idea while ignoring the details that seemed to be overkill, at least for now.

The approach fits nicely into our way of thinking about developing a product.


Small(ish) tasks, where we do know exactly what to do or what to find out. The definitions of these things are soft, and we are still experimenting with a lot of different forms for them. We discovered that writing Ship-its can be hard to get right, and understanding the ask can also be hard.

Some examples of things a Ship-It might be:

  • a bug fix
  • a technological spike to find out if an approach that seems risky is worth to follow
  • supporting our colleagues with something that needs configuration
  • one-off help on a business task
  • designing a workflow
  • writing some how-to or other smaller documentation chapters

As a rule of thumb, we want to have Ship-Its that one or two developers are able to ship within a normal work day. What needs to be done should be clear and no technological challenges are expected.

Push vs pull

First rule: at BetterDoc, we let people pull the work they need to do onto their todo list.

Second rule: Rule One has exceptions.

Almost always, Shapes (or more accurately: projects based on Shapes) are work pushed onto people: the team leads choose who will work on which project. We do this for organisational reasons: projects are handled by project teams that are made up from people all over BetterDoc (not just Product Development), so we need to coordinate who has time when and for how long.

Ship-Its are done differently. These tasks are kept in a list ordered by potentially earned value and priority, accessible for everybody in the team. When team members look for a task to work on, they take one of the first three items in the list.

It is the job of our Product Development lead to make sure items in the pull queue are ordered so that the most important tasks (those that bring the most value) are on top of the list.

Bugs are, by default, always top-level items in the pull queue.

When to use what

Our rule of thumb is as follows: if the Product Development team knows how to do something without deeper involvement of people outside of our team, we make it a Ship-It, unless we see that it would take significantly more effort than one day of work.

If we need input and involvement from colleagues from other teams within BetterDoc, it must be a Shape.

Where to improve this

Like every system in use, our way of organising work has flaws. Lots of it. But: we learn and experiment. We improve, we own it.

Currently, we see these things as our most pressing problems:

  • writing good Ship-Its
  • making sure a Ship-It’s scope is well defined and roughly matches our time expectations
  • communicating upcoming projects based on Shapes earlier to team members to allow team members to have a better understanding if they can be helpful for a project
  • creating well-written Shapes
  • making sure we never compromise on quality to gain more short-term throughput
  • prioritising helping others on started Ship-Its over starting to work an a new ones