Scaling agile with LeSS – Sprint 2

In the previous two posts, I explained why we decided to scale agile, and discussed our learnings from sprint 1.

In this final post, I am going to delve deeper into a couple of areas of LeSS (Large Scale Scrum) and also update on the experiments we have run this sprint.

Update on LeSS ceremonies

In terms of the ceremonies, the experiences have been a little inconsistent:

Daily planning has been going well, with full interaction with the teams and a clear definition of the focus of the teams’ efforts for the day.

Product backlog refinements (PBR) continue to be a work in progress. The product team have come up with a plan for how they would like the sessions to work. However we have not been able to run a complete sprint where the full set of meetings has taken place, and this is something that we are hoping to improve over the next sprint or so. The team are very keen to ensure that the PBRs are working well, as they understand the purpose of them and can see how they add value to the process.

The development teams are challenging the product team to set clearer acceptance criteria for the tasks, to ensure that the tasks can be accepted into sprints with confidence.

Sprint planning (more detail below) has generally gone well, although the team have identified the dependency of the PBRs working well, which will also improve the planning session.

Sprint planning 1

Sprint planning 1 is right at the start of the sprint, where the product owner presents the highest priority items from the backlog, and the teams decide which of these items they are going to work on.

Here is how we currently run sprint planning:

1. Outline the priority backlog items

The first step is to confirm the most important backlog items and make sure that the team are clear on what they are. Each item is written on an index card and placed on the table. (10 minutes)

2. Teams decide what work they will do

The self-organising teams then decide which work they want to do and start taking index cards. We agreed that one team would take on work that they were less familiar with, in order to start the process of cross-skilling domain knowledge. (10 minutes)

3. Split the work items

Each team then splits the work items on post-it notes – with each post-it being less than a day’s work. This means that, for example, if there is three days’ worth of work, then there will be three post-its numbered one to three. (15 minutes)

4. Assess the balance of work

The teams then reconvene to discuss if they each have the right balance of work, and whether they have enough work. If it is found that a team requires more work items, these are taken from the top of the backlog. (10 minutes)

5. Agree the size of each item

Each team then rates their work items as either small (1 days), medium (2 days) or large (3 days). This is then recorded on the backlog. See experiments section below – but we have decided that we should experiment with sizing items during product backlog reviews. (10 minutes)

6. Create the team boards

The teams then clear their boards from the previous sprint, and put the index cards and post-it notes on their physical boards. (10 minutes)

Getting more cross-skilling

The team have begun to look at cross-skilling with the crossover of development languages. We have continued to see good examples of swarming on tickets to ensure that the highest priority work is completed. This has also coincided with the product team adding value measures to the backlog items, to assist the stakeholders and team to identify the highest priority work.

Update on experiments we have run

Capturing emergency work
We realised from the last retrospective that we needed a way to capture emergency work. We experimented by putting new work in a separate swim lane on the physical board – this is where we captured new bugs, any urgent policy changes, or stakeholder requests. These items were then brought to Product Backlog Refinement (PBR) for review and prioritisation with the product owner.

For urgent bugs, we have created a team email address (including the product owner) that bugs are sent to. Depending on the severity of the bug, it is then actioned immediately or again, brought to PBR.

Prioritising physical boards over Trello
Overall this is going really well, to the extent that the teams have stopped using the virtual boards that were set up initially.  But it is still very early days. We think we will need one or two more sprints to refine and hone this further.

The use of physical boards has gone really well, to the extent that the outcome has been the dropping or non-use of the virtual boards that both teams set up initially. The team have really embraced the new ticket system, and this has been working well and also improved with practice, in terms of assessing the number of daily task tickets and the detail included on the ticket themselves, to enable clearer transparency of the work being carried out.

It has also been useful to track work in progress moving visually across the board – before a new item is started.  It has created a good focus for daily planning and for any in-depth conversations that need to take place.

Items that are blocked for more than a day are clearly marked, making them more visible to the team and product owner. This has allowed the team to “swarm” on items to unblock them and get them over the line.

Personally for me, as an interested stakeholder to the process, I have found it very useful to review the board, to stay informed and to have early sight of any trends in blockers that I might be asked to help with.

Using estimated effort over timesheets
We did not make much progress on this experiment this sprint. This was because we are working on pre-existing products, and the business finance teams did not want to change the accounting half way through. You have to pick your battles.

The good news is that we did agree the methodology that we will use for future products. This will be a combination of the number of backlog items completed in the sprint, multiplied by the size of the work item. This is a big step forward in a move to more agile governance.

Experiments for the next sprint

1. Estimations as part of product backlog review
Adding in estimations as part of PBR. We are starting to think about what a PBR is really for. The last PBR in a sprint is the most important for the team so that we have a good platform to go into sprint planning 1.

2. Organisational backlog
We are going to set up an organisational improvement backlog, which will capture outputs from retrospectives, ideas, suggestions and annoyances. We are also going to define more clearly our perfection vision, and then use this backlog to include items that will move us closer to the perfection vision.

3. Metrics and measurement
The team have begun to measure metrics to help establish how successful the experiment is working in general. Separately, we have introduced sprint level metrics so that we can demonstrate the delivery flow for the team, and also identify where or why things have not been achieved as expected.

The indicators that we are planning to measure are:

1. Blocked days (and why): a blocker signalling a dependency, defect or an unavailable skill set
2. Throughput: items done
3. Velocity: measured in points
4. Average lead time: how long it takes an item to get done, averaged up for the sprint
5. Sprint capacity: in person days
6. Defects discovered
7. Defects fixed

The future

This is the last post in the scaling scrum series that I will be writing for a while. However I will write an update in a few months, letting you know how the experiment is going and what we have learned after bedding LeSS in over a longer time frame.

This post is part of a multi post series:

1. Why we decided to scale agile
2. Learnings from LeSS sprint 1
3. Learnings from LeSS sprint 2