Sprint cycles, to get tasks done

As a software development company and Software-as-a-Service provider the TMF team tries to follow and implement Agile software development methodologies to organise its tasks. The team also got inspiration from the online book Shape-up written by Ryan Singer, one of the founders of Basecamp.

Sprint cycles

3-week sprint

Sprint cycles currently have a length of 4 weeks. A cycle consists out of a 3 week sprint followed by a one week cooldown. During the actual sprint; focus is on tasks that were planned beforehand and were added to the Sprint Backlog when the sprint was planned. Follow up on sprint tasks happen in the project module in Odoo. The Odoo dashboard gives a Kanban-style overview of all the projects. There is an integration project for every TMF member as well as some internal projects. Every task has a responsible. The responsible should make sure the task happens during the sprint, but doesn't necessary have to do all the work by themselve.

1 week cooldown

The cooldown week is unstructured. Cooldowns can be used to fix bugs that have been lingering around, clean out support tickets, look into incidents in Gitlab, plan the next sprint, gather information needed for the next sprint through a member meeting, do a release. This does not mean we never work on bugs during an actual sprint or don't do any releases during the sprint. However these type of tasks should only be handled during the actual sprint if this was deliberate choice, with a time budget. An exception would be bugs that are of such a high priority they cannot wait until the next cycle. Cooldowns can also be used to work on experimental developments.

Sprint retrospective meeting

The first monday of the cooldown week a sprint retrospective is held. The team goes over the work of the past sprint and the status of some of the tasks. Good and bad experiences are shared and an improvement point is identified.

Sprint planning meeting

On the Thursday or Friday of the cooldown week the next sprint is planned. Tasks that need to be continued during the next sprint specifically need to be selected again. This is not a guarantee. New tasks can be added to the sprint backlog usually come from the Discovery & Exploration stage and have been prioritazed by the key account manager (using a star) or someone else of the team that was in contact with the member. Every sprint has its color on the Odoo dashboard.

Our Kanban stages explained

Discovery & Exploration

New needs from the members (or new internal TMF needs) that arise are added here. This stage acts as a backlog. Initial exploration of what a solution could look like for the need is done and added to the description of the task. Work that is done in this stage is done asynchronously of the sprints.

Specification

Tasks that enter the specification stage do so because they are selected for Specification during a sprint. During the specification stage the solution is identified, defined and shaped. The outcome of the specification stage can be a list of user stories, a requirements document, a document describing results of research, a design in Figma or just a fat-marker sketch on a whiteboard. When a task comes out of the specification stage what should be implemented, developed, configured in the next stage should be clear.

It might not be necessary for a task to enter the specification stage at all. Straightforward tasks can move to development & configuration immediately or a very short, ad-hoc, specification phase can be done in a few minutes.

Development & Configuration

During this stage a solution for the original need is developed or the necessary configuration is done.

In Delivery

The solution is test-worthy and is being demo-ed to the requesting member. During this stage some fast feedback iterations can be done. If the solution is not satisfactory it might be necessary to move to the previous stage again or even back to specification.

Feedback

The solution is available "in production" and is being tested and used by the main stakeholders involved. Now that the solution has been available in production for a while some more long-term feedback is gathered. When a task moves to this stage an automatic email is send to the TMF member. From this stage a new improvements task can be created of changes are substantial or the task moves back to Development & Configuration the next sprint.

Not now

The need described is this task will not be tackeled now. The reason of this can be that there is no funding for the proposed solution or the task has been sitting in Discovery & Exploration for an extended time period and it's not relevant anymore.

Cancelled/stopped

The task is stopped or cancelled without a solution for the need being fulfilled. The reason can be that the need is not relevant anymore, budget ran out, ...

Done

The need is fulfilled, a solution is available in production. The task is done.