Sprints

As one sprint ends, another will begin. As part of the process, several meeting will need to take place in a short space of time. Planning, review and retrospective meetings will all take place on a Monday.

At the start of each sprint, a sprint planning meeting will be held. This will take place sometime after lunch on a Monday. The aim of these meetings will be to establish the goals for the sprint, assess the required tickets, assign the effort required to complete them and distribute the initial tickets.

The goals should outline the features, bug fixes, test results and documentation we expect to complete during the period.

We will also define what constitutes done for a goal. For example, we want to release version 1.x of a package, or we want to deploy some production code to staging, or we need to run end-to-end testing on this product and here are the tests it needs to pass.

A group of tickets will need to be selected that will make up the work required to achieve the goal. Tickets may have been selected in advance based on their priority.

Team members should be encouraged to volunteer to take on tickets. Where two people volunteer, consideration should be given to effort required vs learning opportunity. Ticket effort scores may need to be adjusted depending on who undertakes the work. Where learning opportunity is considered the most important factor, tickets may be assigned by team leads.

Not all tickets need to be assigned at the planning meeting. Someone working on a 10 or a 15 might only be assigned that one ticket in case the work runs over the expected time. Someone might leave the meeting with five tickets comprising 1’s and 2’s with the expectation they pick up more later in the sprint if all goes well.

The sprint review will be the first meeting on a Monday. The sprint review is an opportunity to look at what has been built during the sprint. This will include demoing any work to stakeholders or the team, gather feedback from stakeholder and the team, updating the backlog and assessing what was planned vs what got done.

Present what has met the definition of done during the sprint. Raise anything that has not been completed during the sprint. In cases where work is left incomplete, try to assess the cause, specifically looking for blockers, team capacity issues and underestimation of complexity.

In cases where we have built something for someone external to the system team, the associated people should be invited to the meeting, shown the progress and encouraged to offer feedback. For system team specific items, this is a chance for the responsible team member to run us through their work and for the rest of the team to openly discuss and feedback.

Once the demos are complete, external stakeholders can leave and the team should work on turning feedback into tickets on the backlogs of the concerned projects.

The sprint retrospective will sit in between the review and planning meetings. The focus of this meeting is us as a team, what went well during the sprint, and what we can do better moving forward.

Reflection on the sprint itself, did we assign too many effort points, are we working on too many separate projects, were there issues getting hold of stakeholders, were the tickets detailed enough.

Examples here could include are we updating the Jira boards enough, is our deployment pipeline up to task, is a tool we are using not fit for purpose, are we missing infrastructure, is the communication sufficient.

This meeting happens weekly and not on a Monday. The idea is to evolve the backlog, preparing it for future sprints. Tasks will include adding new tickets to the backlog, removing obsolete tickets, amending the priority of the tickets, updating existing tickets with additional information, discussing the work required for tickets and assigning them an effort score.

Backlog refinement will be something that happens on a daily basis as we find bugs and understand things better, however these meetings will give us the chance to come together and discuss as a group.

New tickets may need to be added as a result of an ongoing sprint or because of some stakeholder feedback.

It’s important that the number of tickets is kept at a manageable level and removing dead wood should help with this. Developers should not remove tickets from the backlog outside these meeting, but team leads may do so.

Priorities dictate how likely it is something ends up in the following sprint and will likely be updated on a regular basis as we move through a sprint based on the events of that sprint.

This is a chance to raise any questions about a ticket or ask for clarification. It is possible the answer to a question will not be known out of hand and so this will also give opportunity for questions raised the week before to be answered, and for the corresponding ticket to be updated.

The tickets should be scored in terms of effort. Each team member will have a number of points to spend throughout the sprint, and each ticket assigned them will use up their points accordingly. For example, if each team member was given 30 points for a sprint, and we assume a two-week sprint.

Some tolerance above and below the given points is fine, but this should never exceed a couple of effort points.

Leave, bank holidays, training days and meetings need to be considered and should be assigned effort points. For example, if someone has a standing four hours of meetings each week, they would likely assign 2 effort points to meetings.