How We Use Basecamp

Overview

Basecamp is our hub, and our canonical location for all resources and work to be done.

Terminology

  • Work Package – A unit of work to be done. Redesign the logo, Fix overlay, UX for new menu.
  • Work Breakdown Structure – The outline of all work packages in a project and how they fit together.

The Basics: Working with ToDos

Most team members don‘t need to set up projects in Basecamp, they just need to manage issues that are assigned to them. While everyone should read this full document, here are the crucial things you should know about how we work with Basecamp ToDos.

  • ToDos represent work Cantilever must complete, not work YOU must complete. We expect more than one person to touch each Cantilever task. If you have a truly personal task (Send paperwork to Chris/Update Andrew on the thing/Check in with client X), it really shouldn’t be in Basecamp.
  • To-Dos should be assigned to the person or people who must take the next action. This may be the original work, or a review or client communication. If you complete your work or review, you are no longer able to act on the ToDo and you should not be assigned.
  • We do not use the "When done, notify..." functionality in Basecamp. We keep a todo open until Cantilever has completed the work.
  • Broadly speaking, work should be done in top-down order. PM may reshuffle the order from time to time to suit external factors. You should obey the order unless you think it is way wrong, in which case you should talk to the PM.
  • To-do's will sometimes be nested, with "Supertasks" encompassing sub-lists of tasks:
  • image
  • In these cases, the task should be considered complete when all the items in the sub-list are complete. The task should be assigned to any individuals with a next action on any item in the sub list (this often changes too quickly to reliably stick to this convention, but do your best)
  • Rarely should a todo be completed without a check from a teammate. Who must check depends on the circumstances, but generally:
    • Frontend development work should be QA’ed and checked visually by the designer, and code reviewed by another dev
    • Backend development work should be code reviewed by another dev and QA’ed by a QA person
    • Design work should be reviewed by another designer
  • With continual QA, the project should be deployable/deliverable continually after the very early stages. There should be no epic QA, round of revisions, or big launch. The project should be end-to-end stable

Strategy – Discrete Projects

  • The PM will create some initial todo lists, assigning work packages to individual team members.
  • image

  • Team members can break out their work packages in Basecamp or in their own systems. Any todos in Basecamp must match any corresponding parts of the Work Breakdown Structure.
  • Work Package todos should have a link in their description to any sub-lists or groups they contain. Those, in turn, should link to any sub-lists. Use emoji to keep track of which sub lists belong to what.
  • Work Package deadlines represent the next promised delivery of that work package to the client. All sub-lists, therefore, should only ever have due dates which are before the work package. If they do not have a specific due date, leave the due date field empty.
  • If a plan change is required, address all parties with a comment on the relevant which outlines the changes you need. With confirmation, the PM should adjust the WBS and affected todo lists.
  • image

Strategy – Ongoing Projects

  • Work to be done enters an active todo list in the project. There may also be a backlog.
  • image
  • Work Packages can be broken out into sub-lists, with the parent todo linking to the sub list. When the sub-list is complete, the parent is complete.
  • image

Strategy – General

  • For sub-lists broken out from "parent" to-dos, amend the "parent" with a link to the sub-list. Title the sub-list with breadcrumbs illustrating its position in the WBS.
  • image
  • To-Dos should be assigned to the person who must take the next action. This may be the original work, or a review or client communication.
  • Broadly speaking, work should be done in top-down order. PM may reshuffle the order from time to time to suit external factors.
  • Rarely should a todo be completed without a check from a teammate. Who must check depends on the circumstances, but generally:
    • Frontend development work should be QA’ed and checked visually by the designer, and code reviewed by another dev
    • Backend development work should be code reviewed by another dev and QA’ed by a QA person
    • Design work should be reviewed by another designer
  • With continual QA, the project should be deployable continually after the very early stages. There should be no epic QA or big launch. The project should be end-to-end stable.
  • Basecamp now has todo groups. The groups have permalinks, can be commented on, etc, so they are just like sub-lists. They only support one level of nesting, so for now: If you would create a sub-list, and that sub-list would be the final list in the chain (there could never be sub-lists of it), use a BC group instead. There would almost never be a sub-list under any of the formal QA items, for instance, so it’s nice to group them as illustrated here. The groups can be siblings of regular to-dos.
  • image
  • Tasks should represent small, testable units of work. Generally they should be less than 4 hours of effort, but more than 1 hour. If you are spending more time making sub-lists than doing work, your tasks are probably too detailed 😂
  • Tasks should be named in noun form if possible. Ex. "Trash Removal" rather than "Take out the Trash". Home video bug" rather than "Fix issue where home video doesn’t play".

For more information and tutorials on how to use Basecamp, visit: basecamp.com/learn