Talis Engineering Handbook

Planning

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.

Sprints

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.

Estimating

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:

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 priorities¹. 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: