Cantilever Sprints

Cantilever plans its work (both internal and client work) in two-week cycles, called “Sprints.” This methodology is derived from the classic agile SCRUM methodology, but adapted to our particular preferences. Our sprints are two weeks long and a new one starts every other Thursday. A sprint represents all the work (client-related OR internal) that Cantilever is planning to accomplish over that two-week period.

The team’s goal is to:

  • Collaboratively plan sprints that are realistic but also cover the needs and ambitions of project stakeholders across the whole company
  • Complete all the work included in the sprint during the period specified. Each person’s job is not just to complete things that are assigned to them directly, but also to help anyone else who may be behind on any work within the sprint, so the company as a whole can meet this goal.

In October 2022 we also introduced the term EOS that stands for “end of sprint”.

Golden Rules

  • All tasks in the sprint must be clarified according to our workflow. If a task is not clarified but ends up in the sprint, it may live in the “inbox” for a short period while being clarified.
  • Each sprint should have a “Sprint Owner.” This role should rotate around within the team each two-week period. The sprint owner is responsible for conducting the Rituals outlined in our experimental docs.
  • PMs can add items to the “Inbox” of the current or future sprints for consideration by the Sprint Owner.
    • The sprint owner is responsible for approving the item as properly clarified and moving it to the “Ready” section when it is.
  • Sprint projects are not for project management or strategy work, such as clarifications and weekly reports. Those should exist solely in the relevant projects instead.
  • All tasks in the sprint should have a due date that is in the future. Any overdue tasks should be renegotiated immediately.
  • All tasks on the Big Board should have an Estimate and an Importance field populated.
  • The Sprint should be organized by Status. The Statuses indicate where the task is within our workflow.
  • The team should prioritize items closest to shipping and try to clear them out before starting new work.
  • Milestones and sub-tasks should not go into sprints, only actual tasks.
  • Asana-Specific:
    • All internal team members should have access to the Sprint project but external consultants should not, unless there is a specific reason. External consultants should have access only to the specific teams and projects they are actively contributing to.
    • There is now a Cantilever Sprint Tracking portfolio that we use to track sprint completion rates.