Red Green Repeat Adventures of a Spec Driven Junkie

Clean Sprints - How I Help My Team Get to Them

I want to share with you my experience of working with clean sprints.

I walk through my experience of working in a “dirty sprint” style and how the team experienced their first “clean sprint”. I share what I do to make sprints clean.

If you’re not working in a team with clean sprints, I hope this article inspires you to think about it and see that clean sprints are not impossible.

This article will take you about six minutes to read.

Sprint source and more information

Introduction

As a manager, one thing at the core of my philosophy for the team’s performance: clean sprints are the norm.

I have experience where sprints have stories carried over or dragged from sprint to sprint.

Having clean sprints is just head and shoulders better than a “dirty sprint” and once I experienced a clean sprint, I wanted that feeling for my team all the time.

What is a “Clean Sprint”?

Sprints are an agile/scrum term designating in a specific period of time to get work done. A sprint can be a week, two weeks, or even a month long. My preference is for two weeks.

During that time, the team works on specific stories with the goal of getting them “done”.

A clean sprint is when the sprint finishes and all stories are in the done state.

Conversely, a dirty sprint is one where there are stories unfinished.

How did I get into Clean Sprints?

Before, our workstyle would just be queue up stories for the sprint, do the best to get them done by the end of the sprint.

If the stories are incomplete, welp, carry them over to the next sprint.

The sense of urgency to complete the story was not there. Neither was the team to getting all the other stories done.

There would be another sprint, right?

One Fateful Presentation

A team member did a book report on: The Art of Doing Twice the Work in Half the Time Dr. Jeff Sutherland and that emphasized having clean sprints.

After the presentation, the team asked if they can try getting to a clean sprint, like in the presentation.

Sure, why not?

We dived in head first the next sprint, doing whatever we could to get to a clean sprint. The presentation nor the source material would explain this. It’s a “you have to figure it out yourself” for your situation.

Things we did:

  • Capping off the number of stories in the sprint.
  • Scoping down stories if they were too large.
  • Helping each other finish their stories.

At the end of that sprint, the feeling the team had was glorious.

We haven’t looked back since and doing clean sprints are an integral part of my philosophy on team performance.

Pre-Sprint Work

To get to a clean sprint, my approach is to have all the stories as well understood as possible before the sprint starts. That means explaining:

  • Why the story is important.
  • The story’s requirements.
  • What’s the current state of the system.
  • What’s the desired state of the system.
  • How to test for the desired state.

The key idea: once a story is in the sprint, the person working on it will just execute on the story. The story is the plan and they’re executing the plan.

Things not done in the sprint

These are things where which we used to do in the sprint that I consider to inhibit a clean sprint:

  • Doing “discovery work” - figuring out what is going on with the story in the sprint.
    • Resolution: the story needs more explaning, details, clarification.
  • Doing “research work” - finding where to start implementing the story.
    • Resolution: work together to find part of the system to change before the sprint as a team. Technical grooming
  • Testing finds “bugs”
    • Resolution: the story needs more details, especially in the result and how to test.

When sprints were not clean, team members would do all of this work in the sprint.

These activities are high in variability and even timeboxed, don’t produce the best results. I want to shift these activities to before the sprint even starts to increase the chance of success in the sprint.

Sprint Work

As a manager, my goal during the sprint is to:

  • Make sure the team is on track with their story.
    • Hence: standup meetings & status signaling is essential
  • Dealing with any thing “off track” soon, while it’s small (and there’s time before the end of the sprint!) so solving would be easy.

I work with other team members to queue up and prioritize work for the next sprints by scoping stories.

Story Scoping

When the goal of the sprint is to be clean, this ensures I scope the work coming into the sprint appropriately. I ask myself the question:

Can anyone on the team complete this story in a sprint?

If the answer is no, I ask: how can I change the work so it can be?

Methods I’ve used to improve scope

  • Write better stories.
  • Improve clarity on stories by investigating before sprint starts, hence technical grooming meetings.
  • Split large work so multiple team members can approach it at once.
  • Working with team to reduce scope of priorities to be the minimum.

For me, carrying over a story is not an option. I work to figure out to deliver as much of the story as possible. Even if it means creating another story for the next sprint to complete the remainder.

By having the right story scope clean sprints do happen.

Sprint as a Team Effort

Getting software work that is all chunked up and split up into individual pieces so nobody steps on each other’s toes does not lend itself well to working on stories on the same system as a “team”.

That is until I saw the team staying Friday afternoons at the end of the sprint.

The team was there because they wanted to get to a clean sprint together so they were all working together to:

  • Get their individual stories done.
  • Pairing with each other to get stories done.
  • Code reviewing each other’s work right away.
  • Testing out each other’s work on integration environments to validate work.

I always thought Fridays were slow days, here, my team was showing me intense focus that I didn’t want to get in their way.

This is how the engineering is a “team sport”.

Conclusion

Getting to a clean sprint is a great feeling. The team works together in a manner to finish all the stories. The fact that stories are done at the end and everyone can start fresh for the next sprint.

I enjoy the clean sprint feeling so much that as a manager, I work to make sure my team gets to a clean sprint every time. This involves:

  • Putting in pre-sprint work to ensure stories have details, clear, and for anyone on the team.
  • Do “system discovery” work for the story together.
  • During the sprint, I ensure team is on track and help them get back on track while problems are small and there’s time before the end of the sprint.
  • I also work with the team to scope the next set of sprint stories so there’s always stories ready to go.

Going from having sprints where dragging stories from sprint to sprint was the norm to having sprints to be “clean” took one presentation and one experience.

All it takes is one experience of a clean sprint, and you’ll be working to achieve this feeling over and over.