Last year I lead an engineering team for 5 months. During this time we practiced SCRUM, which enabled us to predictably accomplish what we committed to. Predictable delivery is essential for mid and long term projects, where missing commitments could put deadlines at risk. This post outlines what we achieved, how we operated, and why it matters.

5 Months of Scrum

The team I lead used the scrum methodology for 5 months, while we were together. This allowed us to predictable deliver on our commitments. We did this by leveraging the concept of “Under commit and over deliver”, which increased our estimation accuracy. The chart below shows our performance over the 5 months the team was together:

A value of 1.0 represents our sprint target; it’s what we committed to in a given sprint. Any value greater than 1 means that we delivered more than we committed to.

The chart shows that we met (and exceeded our commitments) on all but two sprints:

Generating these metrics required us to stick to the sprint process which I’ll cover later in the post.

Even though we worked in 2 week sprints, adherence to our process allowed us to deliver on 4, 6 or any number of week initiatives. We decomposed longer initiatives and applied the process, set an explicit scope for the 2 week sprint and use the overarching goal as an end deliverable to work towards.

I think of the team as a mechanism to turn ideas, business goals, or initiatives into concrete fully finished capabilities.

Why Does Predictability Matter?

Predictability is required to plan work into the future. The organization created a multi-quarter roadmap, outlining the key initiatives that we wanted to deliver during 2021. Below shows a 2 month snippet of the roadmap:

Since teams have a fixed capacity at any given time, working on one task necessarily means other tasks won’t get completed. If a task is expected to complete in 2 weeks, but actually takes 3 weeks to complete it results in the following tasks being delayed:

Teams need predictability to be future facing. When a team lacks predictability, any task can take any amount of time. This creates a reactionary way of working. A task comes in, it takes as long as it takes, and then the next task is addressed. A team might appear to get work done in a reactionary setup, but it often comes at a cost in terms of stress and lack of strategy.

Predictability empowers a team and allows them to look forward to the future. A team decides on what they want to execute, decomposes the goal into individual deliverables, and then ships those deliverables with a high degree of confidence in how much time and effort they take. Predictable teams are mature teams.

How Did We Achieve It?

In my experience Scrum, consistently generates predictable execution. I participated in, and led, scrum teams as a technical IC previously for ~3 years achieving similar results. The processes are lightweight, easy to understand and value focused.

A strategy that I’ve found to be effective is: “Under commit and overdeliver”. Under committing isn’t doing less work, it’s setting clear expectations on the work being delivered and accurately allotting plenty of time for interruptions.

Couldn’t we just commit to a day's worth of work every sprint and then overdeliver? No, we’re a team of professionals that want our employer to succeed. We also have pressure to meet our roadmap commitments. We didn't operate in a vacuum.

The following lists the components which I feel have been instrumental in achieving results.

Process

Strict adherence to the scrum process is essential. Our process involved:

• Capacity Forecasting (we used a lightweight spreadsheet)
• Planning - Clear & explicitly scoped and agreed upon goals for each sprint
• Execution & Keeping our jira stories up to date

The process overhead accounted for ~4 hours every 2 weeks to maintain. Before every sprint I ran the numbers to calculate our working hours and subtract any known interruptions.

I used these numbers to forecast our human capacity for a given sprint.

Everyone on the team needs to participate in the process or else scrum falls apart. If jira stories aren’t updated we are not able to calculate the metrics and measure our progress and effectiveness.

Measurement

The unit of measurement in scrum is a "Point". Scrum functions as an engineering account system which is able to track and project capacity, and velocity in terms of these points. Points in scrum can be hard to understand as they represent complexity of a task and not wall clock time (wallclock time being something like 4 hours, 1 day, etc).

Scrum measurement warrants a post of its own. Adhering to scrum and leverage points surfaces a number of important metrics which help to debug team performance and track our effectiveness over time. The empirical data makes it easy to understand team performance and identify blockers.

We need measurements to build up data so we can reflect and project. Leveraging historical measurements allows us to identify sprints that didn’t go as expected, reflect on them, and figure out ways to address the issues, then measure our efficacy in addressing them.

Explicit Expectations

Setting expectations requires knowing what is expected for the team, but it also involves communicating that we as a team are strictly adhering to this process. Management communicates their expectations for the team by defining a clear mid and long term roadmap and clear & explicitly scoped and agreed upon goals for each sprint.

As a team I set expectations with management on what we can reasonably commit to, but I also set expectations with stakeholders by explaining that requests get funneled into our scrum and planning process, which operated on a 2 week interval.

Backlog Ownership

A backlog owner is responsible for the priority of work. My manager was our backlog owner. They made the decision on which work items we addressed and the order they should be addressed. While we had an open 2 way and collaborative communication path on building our backlog, the final call was the backlog owners. This is really important when setting expectations. Remember we had a fixed (and measurable :p) capacity each sprint. Working on one item necessarily means not working on another item. We needed to understand the business goals and priorities to make sure we focused on the highest value items, and the backlog owner acted as our link to the business context.

Conclusion

I’ve found scrum to consistently provide an effective way to predictably forecast and execute work. It’s lightweight and easy to understand. The measurements it surfaces allows for debugging teams. I’m super excited about our performance over the last 5 months and hope to write more about our capacity forecasting and work decomposition approaches.

Thank you