Skip to content
We are always hiring


Planning repository

Each sub-team within the Engineering team should work from a single GitHub repository, with a Zenhub workspace to track their sprint. This provides a simple view of a sub-teams work and also ensures all sprint work counts towards reporting.

The team process must be documented in the planning repository, so that others can understand how to interact with the team. This should include things like how to contact the team, what to expect from a process perspective when working in team projects, and the process for raising and discussing issues.


We work two week sprints across the teams, but the precise process can vary between them. The sprint contents should always be decided in advance. Sprint issues should be kept in priority order, so that higher-priority issues are picked up before lower-priority issues.

Ramp-up planning

New team-mates are not expected to immediately contribute to planned sprint work. Instead, their work comes from a separate “ramp-up” pool of issues. These issues are intended to encourage learning and practice, but are protected from the delivery expectations of a sprint. Ideally, these should follow a similar process and structure to the planning repository.


With team velocity being a good indicator of what a team can achieve in a sprint, a shared common points-to-person-time across the teams will provide a quick understanding on effort required. The rule of thumb for the following points within the Fibonacci range is:

Points Days
5 1
21 5
40 No idea, break down story / > 10 days)

The number of person-days derived from points assigned to an issue is not necessarily how long it will take to deliver that issue. We choose to use person-time-to-points because in practice that suits us better when thinking about a task at hand. In reality there are usually other time-based factors that affect a piece of work. When a team thinks and estimates this way, it is natural and expected that velocity is less than the total time available to that team in a sprint.

At the start of a sprint, every story must have an estimate. All Theme and Non-theme issues must have an estimate before the sprint starts. The entire team is responsible for understanding the work involved and contributing to the estimate. The only exceptions for estimates are for issues marked Triage, which enter during the sprint and the point-scope is not known until completion (see below).

Estimates on planned stories should never be altered once a sprint starts. Issues that are introduced into the current sprint with the Triage label are allocated points for the actual person-time it takes to complete. If Theme or Non-theme issues are radically different from their estimate, it’s worth noting this on the issue, but leave the original estimate in place.

Sprint size and pull-forwards

We should aim for our sprints to include a realistically achievable amount of work, based on the issue estimates and team velocity (don’t forget this drops when team-mates are on leave). The aim here is for the scope of the sprint to be a relatively reliable indicator of delivery, so that others can expect that if a story is included in a sprint, there’s a strong chance it will be delivered.

Of course, we do not expect this to be perfect - there are lots of factors that can affect how a sprint progresses. If we are left with issues unresolved at the end of a sprint, they are subject to the next sprint’s process; if we exhaust the sprint issues, we should “pull forwards” estimated issues from the next sprint, in priority order. It’s good practice to include a pull-forward label in these cases.

Project and Theme work

Zenhub Epics should be used to track issues against a theme of work drawn from our Product roadmap. Examples of this are “Kubernetes Migration”, “Mobile Annotations”, etc. Epics provide an overview of how a theme of work is progressing. It is not a complete picture from inception, but should represent the overall effort and progress of a project.

10% time

Team members are encouraged to allocate 10% time in the sprint that can be used for research and development, learning and professional skills development, productivity improvements, and other tasks that are not directly related to the sprint or technical priorities1. Allocating this time is done by creating a ticket with 10% time label that enters the sprint just like any other sprint work. 10% of a sprint is about a full day or, in terms of estimates, 5 points, but you can use it whenever you like. Also, it’s based on the sprint time, so your annual leave does not affect it.

The important thing is not to feel pressurised about any work done within 10% time, e.g. if you need to learn more about a topic in order to complete a sprint-related task, you do it as part of said task. What you do at this time is your personal choice, and it should be something that’s fun and interesting to you.

If the output of your 10% time is contributing to a project, discuss with your team how you can make it a part of the codebase so that it follows the same process as any other changes you would make on BAU.

Mutually exclusive reporting labels

Labels are a good way for us to distinguish between and filter our issues. We can also use them to report on where we are spending our effort. In order to track effort, every issue should have a mandatory mutually-exclusive label from the set below:

Label Description
Theme Theme work is specific goal focused project work that at a future date will be completed. That goal can be a product feature or technical strategy. A single theme usually maps 1:1 with a Zenhub Epic. Mobile annotations or implementing LTI 1.3 would be a theme, but something like continuous improvement or ad hoc technical debt would not. Issues that are created and placed into the current sprint that relate to a theme should be labelled as Theme.
Non-theme Issues that are not related to theme work but are planned in accordingly, even those created from existing planned work within a current sprint. Examples are continous improvement, technical debt, and tenancy setups.
10% time Personal development tasks, see above.
Triage This is applied only to issues that enter the current sprint, and that are not created due to work currently in the sprint. Examples include: support requests, pager duty alerts, tenancy admin, fixing broken builds etc. At the start of a sprint no issues should carry the Triage label.