Red Green Repeat Adventures of a Spec Driven Junkie

Improving Sprint Performance - Part 3

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. The second part I go over changes I made external to my team.

This time, I discuss changes I made internal to my team, changing work-flows of team members that report into me.

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

This article will take you about six minutes to read.

Jean-François Millet - Buckwheat Harvest - Summer source and more information


A manager can improve a team’s sprint performance, first with measurement. Next, I made changes to how to work with external partners is one way to improve the inputs to the team with the idea of: better inputs results in better outputs.

This time, I describe initiatives I introduced to improve the sprint performance of my team, specifically:

  • Pair Programming
  • Technical Grooming
  • Improvements in Signaling

These changes did not lead to immediate improvements, all took time to implement and results appear indirectly.

This is how the team’s velocity changed over time:

Velocity Chart for first Fourteen Sprints

Most importantly, I had stories in the first four sprints and after I did not have any stories at all.

Talk about a win-win-win, right?

Pair Programming

I find the most effective way of transferring problem solving knowledge is to pair program with individual team members.

This allows us to interactively work on new problem, share knowledge through discussion, demonstrate how I would approach the problem, and get work done.

I schedule a one hour session with each team member every week, especially early in the week so they will have the rest of the week to work on the problem and/or come back with more questions.

Technical Grooming

Having space for the team to discuss how to solve upcoming priorities allows the team to be on the same page for a story. This gives additional time to brain storm, consult with other teams, do research internal and external to the system.

I’ve written an article on how I run this meeting.

In my implementation, I schedule one hour per week with whole team. I will schedule additional meetings if there stories needing review for the next sprint.


I need to let the team work on their own and solve problems.

At same time, I need to know when they need help so we can stay on track, resolve problems while they are small before blowing up into a crisis. I implemented the following to signal:

  • Written Stand Up Reports
  • Status & Time to Pull Request
  • Hurdles

Written Stand up

In previous experience, stand up felt like a chore. We would all get together and just say what we did the day before. Each stand-up felt random, uninformative, and if you missed it - you would not be able to give your status AND you would not get other’s status.

This is a problem when managing the team, especially not getting others’ status on their work.

For my team, I changed the stand up format to have the team write and send their stand up report sent to a shared chat.

Having a person’s stand up report written into a shared chat channel is refreshing.

  • Asynchronous: One does not need to be there to give or receive report.
  • Record: always refer back to it, especially diagnosing problems with larger time frames than a sprint.
  • Think through: by writing, one can think through what they did instead of anxiously giving the: “this is what I remember doing yesterday…” rambling stand up.

Stand Up Report Format

Instead of having free form stand up reports, I standardized the format to answer the following questions:

  • Status: (Green/Yellow/Red)
  • What did I do to move the sprint forward?
  • What will I do to move the sprint forward?
  • Blockers?
  • My next set of hurdles are

Status: Green, Yellow, Red

This is a general overall signal to say if you’re on track, little off course, or need help.

When a status is yellow or red, I would allocate resources to the team member to get them back on track or identify how else to solve the problem.

Note: in no way does being in a non-green status would mean a negative evaluation, not being honest of your status would!

At first, I had this status as a “feeling”. Dan Dela Rosa, a team member, suggested correlating story points as the number of working days to making a pull request.

  • Green: Pull Request made within (story point) working days.
  • Yellow: No pull request after working on (story point) working days and less than the (story point’s next Fibonacci) working days
  • Red: No pull request after (story point’s next Fibonacci) working days.


A three point story would mean the team member would have a green status for three days.

  • If there’s a pull request for the feature within or by three days, all good.
  • If after three days and before five working days, one’s status would be yellow.
  • After five days, one’s status becomes red.

Yellow/Red status would have different level of intervention.

  • I could just pair with the team member more.
  • I would investigate issue with the team member and evaluate if there’s a simpler solution. If so, I would talk to the original story author about this change.
  • A case that has happened is having the whole team drop their work to help a team member’s work done.

With the proper signaling, I know when the team is in trouble. I can address their problem early instead of later.

Most importantly, make sure the team finishes their work and delivers on their commitments.


Another part of the status report I ask my team members to list is what upcoming hurdles they have.

What steps do they think they need to overcome to solve the problem?

This helps me make sure the team member is on the right track and avoid getting into a non-green status earlier.

As a developer, I know tangents happen, rabbit holes appear out of nowhere. I want to make sure they come back before getting too far off track.

Having these hurdles help me see into the team member’s thinking process.


As I had implemented changes external to the team earlier, I slowed down new changes as the team did express change fatigue.

This is true, I need to see how external changes affected overall performance.

This is the result of the team for sprints 1 - 14.

Velocity Chart for first Fourteen Sprints

In the next set of sprints, changes were only internal to the team. The only change listed in this article not implemented in the sprints was the status to story point signaling.

One thing to note, the team started to commit to about the same amount (there are variations due to time-off) at the same time, the team starts to deliver more than their original commitments in sprints 10, 11, 12, and 14.

This is a good sign as it means we can deliver on commitments and more.

At the same time, I don’t have any stories in these sprints at all. This means all the delivery is from my team, not from me.

Looking closer at what issues and bugs were in the sprint:

Velocity Chart with Issues and Bugs for first Fourteen Sprints

The number of bug issues dropped from sprint 7 and never go up. The number of issues stay about the same, with higher completed points delivered.

With more points delivered and constant feature story count, the team is delivering more points per story.

Another good sign: Less bug stories means less “free” work. Less free work, better velocity.


Internal changes to the team with better signaling such as written stand up reports, better green/yellow/red correlation, and hurdles, technical grooming sessions with the team, and consistent pair programming made the team’s output stead over time and eventually leading to delivering more than original commitments.

Combine the internal changes with external changes help improve overall team output.