Sprints

Opposite to what people often think, sprints aren't about wildly executing work as fast as possible. Sprints are a means to being efficient at what we do by making use of a number of rules that increase shared understanding and reduce incertainty. The sprint is therefore not an action or a meeting but a time-box of events that keep the team going, making our work clear, organised and estimable. A sprint can endure for as much time as the team wants but it's been found that 2 weeks is a balanced duration. In order to have predictable planning, it's important to commit to a standard duration for the same project.

Sprint prep

We have found to be a good investment of our time to do a quick half an hour meeting a couple of days before the next sprint starts. This includes the very first sprint as well. The idea is getting engineering and project leads together to make sure there is enough information to get a solid sprint going. This includes analysing if the user stories are suitable to be assigned, double checking on staff availability for the sprint period as well as having any outstanding questions answered. Having these solved, contributes for a much more efficient sprint planning.

Check the Sprint prep guide

Sprint meeting

Check the Sprint meeting guide

Review

Every development sprint ends with a demo to the whole team, presenting the latest on a big screen. Doing this sets a pace and, more importantly, creates a routine where people expect to periodically see what's new. This is a convenient way for everyone to quickly review what has been accomplished, a good opportunity for feedback and also a way to ensure that we're all on the same page with how everything is progressing.

Planning

Now that we know how much was accomplished, it's time to plan for the next chunk. Because of the previous sprint prep meeting, this moment ends up being easy and transparent. This will be the final call on priorities and detail. Usually, any leftovers from the previous sprint are top priority and the same goes for bugs and corrections that affect what has already been done.

We like to start by looking at the Project Board and going right to left, from what got done all the way to what's next on the pipeline. The team quickly double checks everything and discusses how much work from the previous sprint is still left. With this feedback, the team can plan how much more work is reasonable committing to.

Engineering

Up until now, the team has been committing to work in terms of User Stories. Those are great to define the product and get the team speaking the same language but, at some point, the engineers need to break them in a way that makes sense for them. So, immediately after the sprint planning meeting, the engineers have their own meeting to go through the technical details of how they need to go about their work to deliver what was agreed. The most senior engineer will lead this meeting, making sure the tasks are distributed in an efficient way. These tasks can later also be added to the Project Board making sure their description includes a reference to the User Story they contribute to. Doing this has helped us understand how bigger user stories are progressing instead of just having them frozen on the "In progress" column.

Daily standup

Daily standup meetings have huge benefits. They require very low effort but, in return, help us keep focused on what should be done. It's common for team to start drifting away from the initial goals, even when careful planning took place. Allowing that to happen for over a week can bring pain but when it's caught early on, it can be more easily dealt with.

The basic rules are simple. Never skip a standup and stick to the three simple questions: what have you worked on yesterday? What will you work on today? What is preventing you from doing your work? Don't go into unnecessary detail, specific discussions can be happen at a different time. We like doing our standups early on, as soon as everyone from the team is in the office but, if there are remote team members, it's a good idea to set a 15 minute time-box that determines how long you should wait.

Check the Daily standup guide