Red Green Repeat Adventures of a Spec Driven Junkie

Improving Sprint Performance - Part 2

This is the next article on how I improved my team’s sprint performance. The first part, I discuss the situation and our sprint setup.

In this article, I discuss changes I made external to the team to improve the team’s velocity, highlighting changes that involve the product manager and QA team.

If you’re looking to understand how to improve your team’s velocity with your partners, you can see what I did in my situation.

This article will take you about six minutes to read.

Jean-François Millet - Le Printemps source and more information

Introduction

In part 1, I talked about the team’s velocity chart showed a trend of increasing commitments with stagnant completion rate. The problem kept getting worse with more people on the team.

The team’s velocity has to improve as my manager measure my output based on the team’s velocity.

I go over the changes I made external to my team, working with partners of the team: product management and QA, to change:

  • the definition of “bug”
  • sprint stories details
  • planning commitments

These took work and slowly improved the team’s velocity over the next four sprints:

Velocity Chart for first Eight Sprints

Excited to learn what I did? Let’s go!

Bugs Hinder Velocity

Velocity Chart with Issues and Bugs for first Four Sprints

On the above chart, the number of bugs kept increasing with successive sprints. This hinders the team’s velocity as anytime there’s no work on feature stories, the velocity does not go up.

Where are the Bugs Coming From?!

Investigating the root cause of the issue, I realize the issue is not that the team was doing buggy work, the bugs were coming from under-specified stories.

When a feature story is under-specified, two things can happen to get the story finished:

  1. The team member could go to the product manager for clarification, implement based on their side-channel conversation.
  2. The team member could make a “best guess” based on current system understanding and intent from story detail and/or grooming meeting.

With choice 1, this conversation happens in the side-channel (in person, chat, email, etc.) and is not documented in JIRA. This affects the QA team, based on their understanding/interpretation of the JIRA story, may require another conversation and/or file another bug because of this missing side-channel information.

With choice 2, this is also not documented and if the engineer is:

  • lucky, the decision worked out with product and QA, on to the next story!
  • unlucky, the decision was wrong, QA creates bug issues against the feature story, more bugs.

Either choice hinders productivity and leads to bugs.

INABIAF

When the behavior is ambigious, one can make an argument that the existing behavior is not a bug, it’s a feature the user/product/QA has not realized to be beneficial. INABIAF, which stands for:

It’s Not A Bug, It’s A Feature source

In essence, any “bug” can turn into a feature with enough effort.

Redefine: “bug”

Instead of having this INABIAF discusssion every time with the product manager and/or QA after an under-specified story, I ask that bugs follow a simpler defintion:

A bug is behavior that violates specified behavior in a story.

This has an effect of:

  • Specifying all behavior for a feature in a story.
  • Creating documentation for the system in the JIRA story.
  • Focusing bugs stories to be in a specified scope.
  • Holding engineering accountable to implementing only specified behaviors.

It’s a simple definition that everyone can understand, existing team members and new team members.

External partners, product manager and QA, were not on the same page as me and it was an uphill battle. This wasn’t the only change I made at the time and I share my experience in the implementation section.

Additional Story Details

Along with a new defintion of bugs, I ask fleshing out more details in feature stories. In essence, following the format introduced in article: writing better sprint stories.

Why?

This would have a synergetic effect by reducing “bugs” and/or making “bug” stories easier to write.

Fully fleshed out stories would reduce any ambiguity from the story author to engineer implementing the feature. When you know everything up front, you would know what to do.

There is nothing worse than having a story “grow” as you implement.

Story Length: Before & After

I did a quick check into the story lengths before and after:

words min max
before 50 250
after 120 600

Imagine expecting to work on sprint story with only 50 words as its description, then getting “bugs” written against your work.

As an author of technical stories, I was guilty of under-specified stories too. It was painful for me to admit it, especially as one who would “know the work”, this change was to improve the team’s output, not just my work.

Commit to One Story at A Time

The final change I asked the product manager to change to improve our velocity: assign only one story per team member - ala Kanban style.

The way the planning meeting of the start of a sprint would go is:

  1. The product manager presents all stories needed for the sprint.
  2. The product manager would ask who could take stories and assign until a team member had 10 points assigned.
  3. Start sprint.

The number of stories queued would work out to ten points per team member. A metric I agreed upon. Remember how “bugs” don’t have points…

Given the completion rate of the team for the last four sprints of 33%, I changed the number of stories queued up in step two. I changed the number of stories queued up for planning to be one per team member.

I ask the product manager to queue the remaining stories for the sprint so members to take as they complete their stories.

Results of this change:

  • Balance out workload for the team, especially if they go on vacation and/or (heaven forbid) got sick.
  • Force the product manager to have the top priorities queued first, not in a big list (which gets lost amongst the engineer’s queue and/or priorities).
  • Build team confidence in getting stories done consistently.
  • Help me monitor progress of each team member.

Most importantly, have the team stop “over-promising”. It’s too easy to commit to more stories at the beginning of a sprint when your queue is empty and you really don’t know how much each story is (even with sprint points!)

Implementation

Getting these changes implemented was not easy. As much as I want to say I have full control over parts of the sprint process, I do not and I need support of external partners in getting changes done.

  • QA - responsible for finding bugs and engineering are delivering stories requirements.
  • Product Management - responsible for creating feature stories for engineering and setting the priorities.

Both partners had a lot of resistance against my proposed changes. In both cases, I did not (or even think of) “going to their boss” or have my boss go to their boss to change their minds. I worked with both partners individually and came to resolution.

QA

The bug definition definitely irked the QA team who’s goal is to “filing” bugs, not creating stories (which is the product manager’s job!)

This change took time too as getting additional story details increase took time. I also requested changing filed bugs to stories as some bugs did not indicate which story the behavior violated.

As the story detail improved, this made QA’s job easier because there’s less ambiguity to interpret.

Product Manager

Of all changes, the story detail requirement made the product manager most furious. This requirement added to their already stressed workload, this change would mean there’s more work.

This change consumed a lot of the relationship capital I built up with the product manager and took time to build up again. At the same time, as results came in, the relationship improved faster.

Over time, I saw a significant improvement in the product manager’s ability to reason about the whole application as stories were more fleshed out, even challenging other team’s contribution and/or consistency in our grooming meetings. I am happy the product manager trusted me enough to make this change.

Result

Velocity Chart with Issues and Bugs for first Eight Sprints

The velocity chart for sprints five to eight shows:

  • The team is not “over-promising”.
  • Two clean sprints, with one over-delivering.
  • When sprint is not clean, only missing 30% of total (approximately one story not done.)
  • Consistently getting things done.
  • Bug issues are down, feature stories are up!

This is a significant improvement over sprints one to four for the team’s velocity.

Conclusion

Improving the team’s velocity by managing external factors outside the team involved:

  • Changing the number of stories assigned to one per team member at the start of the sprint.
  • Improving stories to have more details so there are less ambiguities.
  • Redefining a “bug” to be violating a previously specified behavior.

Getting these changes meant working with external partners such as the product manager and QA team. Each required using relationship capital for changes.

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