Improving Sprint Performance - Part 1

I want to share the first part of larger process I took to change my team from under-delivering to over-delivering on their sprints.

This is the first part where I describe what I did to get my team from under-delivering to over-delivering.

• Part 1 (this article)
• Part 2
• Part 3

This article describes the sprint setup, performance measurement, and current situation. In the next articles, I will describe actions I took external to the team and internal team changes to have the team consistently deliver.

As a technical manager, I haven’t found resources to help a team’s output, so I want to share my learnings with goal of helping others.

If you’re managing a team and want to improve their output, I hope this article will describe the setup in my team and inspire you to improve your team. If you are thinking of being a technical leader, you will understand part of the job.

This article will take you about five minutes to read.

source and more information

Introduction

As a manager of a team, my manager measures my result by my team’s output, not my own. This makes the sprint result important to me. I can’t just ignore it as it will affect my performance rating.

This is one of the biggest difference from being a contributor: I don’t have direct control over the result that influences my rating.

So, instead of crying about the indirect measurement, I dove down and figured out what this measurement is all about and how I can make it work for me.

Sprint Configuration

First, just to explain how the team does sprints. I would like to think we take a standard approach to our sprint:

• The sprint length is two weeks long.
• The user facing stories author is the product manager.
• Technical stories come from the technical leader.
• There are bug stories, that the QA team writes whenever they find a bug in the application as they are manually testing. These items are not pointed.
• Engineers point stories in the grooming meeting.

Meetings

The key meetings we have during the sprint:

• Grooming
  • This meeting is for product to introduce features to engineering, discuss details with other functional departments such as design, data engineering, etc.
• Planning
  • This meeting is for product to close the past sprint, list stories or bugs for the upcoming sprint, and engineering to decide who will be taking which stories/bugs in the next sprint. The sprint officially starts after the end of this meeting.
• Retrospective
  • This meeting is time for everyone in the sprint to provide feedback on the past experience, suggestions for improvements, or just vent.

Measurement

The way my manager measures how successful a sprint is for my team is to use velocity charts.

The calculation for a velocity chart is:

• sprint points committed at beginning of sprint
• sprint points that are in Done column when sprint finishes

In general, the blue is the committed column and the green is the delivered column. I will discuss the above more later.

Own Measurement

At first, I did not use velocity to measure team’s output. I felt I knew my team better and could devise a better way to get higher team output using past data and an algorithm that’s customized to the team.

Well, I seriously regret doing it as calculating using my devised method added too much manual work at the end of each sprint. It was so much work that I didn’t even do it consistently.

Another down side: it was not well understood, so I would not have any resources to learn from.

Taking a standard measurement is beneficial as:

• JIRA generates this report auto-magically
• everyone on the team can see the result
• there’s literature on how to improve

I learned the hard way: use the standard tools whenever possible.

Current Results

Given those sprint details, the velocity report of the last three sprints are:

For these sprints, I had stories that contributed to the main sprint deliverables, so I am in the team.

This is the velocity chart for the first four sprints:

Given the results of four sprints, these are trends I am seeing:

• The team is committing to more work each sprint. That’s great to have a team taking on more work. In this case, the team had new members added, hence, it would commit to more work.
• The team’s deliverables remained constant while commitments grew. This is not a good sign as the expectation of the team growing is output would grow!
• The team would just deliver on 30% of its commitments. How can anyone plan with 30% delivery rate?? (Baseball coaches, ssssh! :-) )

Another thing not directly viewable in the velocity chart - the number of stories vs bugs the team worked on:

The number of bugs the team working on increased and accounted for the majority of the work. As bugs are not pointed, this means the team was doing free work. This work is essential, it reduces the team’s output.

Not a good trend.

Looking at this, we see:

• In four sprints, team only delivered about 30% of its commitments.
• Adding more people didn’t improve delivery. There is mythical-man-month in effect here.
• The number of bugs kept increasing, hence reducing productivity.

Given that’s the current situation, where do I want the team to go?

Desired Results

No matter what, want team to have a Clean Sprint. A sprint where all stories at end of sprint are in DONE column.

Next, I want the team to deliver on their commitments. If the team says they will do n stories, deliver n stories at the end of the sprint.

Finally, I want the team to over-deliver whenever possible. That means deliver on their current commitments (fulfilling product’s priorities) and additional commitments (going beyond!)

What does this look like? Something like:

Getting the team to this point took a lot of work and I ultimately was able to:

• stop team from over-promising
• start trend of over-delivering
• reduce bugs worked on
• increase issues worked on

All without:

• adding/changing team members
• doing more work myself (I actually did less work)

Sounds too good to be true? Come back to learn what I did to achieve all of this.

Conclusion

Understanding my team’s output is crucial, especially as my manager determines my output based on the team’s output.

When looking at the velocity chart for recent sprints, I saw a terrifying trend.

Understanding how the sprint works is crucial in improving the team’s velocity as those will dictate the levers I have.

In the next article, I go over the changes I made external to my team to improve the team’s velocity.