Skip to content

Eight week cycles

Our time is split into 8 week cycles:

  • 6 weeks on long term important work, split into 3 two week sprints
  • 2 week cool down

The goal is to maximise our time and effort working in a focused way on long term important work. Often this kind of work is not urgent so we must schedule it in.

Eisenhower decision matrix

We allocate as much of our time as possible explicitly to this long term planned work.

Six week project cycles

During the cycle we focus on only two types of work:

  • Planned project work
  • Urgent user or business issues

Everything else we ignore.

This gives us six practically uninterrupted weeks to focus on the work that is going to make the biggest impact to the business.

Two week sprints

We plan our work in sprints, each lasting two weeks.

At the end of each week we have a demo meeting where everyone gets to show off their progress. This is on Thursday at the end of a sprint, and Friday otherwise. Having the demo on Thursday lets us decide how to ensure that the project is finished and leave time for that to happen.

Circuit breaker

At the end of the six week cycle all work must be finished. This is to avoid work spilling over into the cool-down week and disrupting it.

If work can't be completed within the cycle then the project by default does not get an extension. There is a risk the project, as specified, won't happen:

  1. This eliminates the risk of runaway projects
  2. The project we defined was too large
  3. It motivates everyone to take ownership over their projects, including the scope and implementation details. If it will take too long, the person or team responsible make a hard decision about where to stop, what to compromise, and what to leave out.

Releases

We release Sourcery every two weeks on Monday. This ensures that the work from a sprint gets included in the product as soon as possible.

Cool down

The cool down weeks are split into two.

The first week aims to be as unstructured as possible. There is very little scheduled work so everyone is free to work on whatever they want. We can explore new ideas, fix bugs, or try out new technical possibilities. During this first week the founders also meet in person to work out the priorities for the next cycle.

The second week is more structured. The aim here is to:

  • Finalize the plan for the next six week cycle.
  • Work on spikes that will help inform the work for the next cycle, as agreed with Nick or Brendan.
  • Fix bugs or Enhancements from the backlog.

We also might hold hack days, data deep dive days, or anything else fun or that will help us all improve as a team.

Retrospective

During the first cool down week we hold a retrospective on the previous cycle. This helps us to reflect on what went well and not so well, and identify any changes we may want to make to processes going forward. It may also help to inform the planning process for the next cycle.

We first asynchronously add notes to our owned projects, identifying the Outcome state we think it is most likely to achieve, and any thoughts on how it went in the Retrospective Thoughts field. We can also add general thoughts or learnings - these are then discussed in a meeting during the cooldown week.

Then for each project we decide whether it can be moved to Completed status. This is the time to see if follow-up projects need to be added, either to finish off features which have been cut, or to exploit the results.

Resources

  • Shape Up - almost all of the ideas above came from here