Have you ever had a sneaking suspicion that something's holding the team back, but you can't quite put your finger on it?
First: Velocity
Has a client ever asked you why the team isn't going faster?
How about that time when the team got to the end of a sprint and had to talk about why they finished fewer cards than expected?
Have you ever wondered why it's taking so long to get cards done?
We're basically talking about a team's velocity - the number of story points completed in a sprint (or, the business value created in a sprint.)
Many factors can impact a team's velocity during a sprint:
- Sprint length
- Scope creep
- Changes to the team
- Changing business priorities
- Bugs and production hotfixes
- Vacation and holidays
- Sick team members
- Dirty code
- And more
Some factors above, like your sprint length, can naturally help your velocity - if you have a longer sprint (say, 2 weeks instead of 1), then chances are high the team will clock a higher velocity at the end of the sprint. Other factors are just a fact of life (people get sick; clients change their minds; death and taxes are inevitable) or more subtly pernicious (left alone, dirty code leads to tech debt, which leads to slowdowns.)
Check Yourselves
If the team addressed the obvious culprits but you have a nagging feeling that they're still not optimized, what do you do?
Every now and then in situations like this, I recommend teams bring out a handy tool called the Drag Bucket. Here's an example of what one looks like:
The Drag Bucket is a simple, low-tech concept: anytime during the sprint that the team finds itself pulled away from heads-down work, we log drag.
What is drag? First let's examine what doesn't qualify as drag:
- Implementing or writing tests for your story card
- Research or chores related to the story card you're working on
- Bugs related to the card you're working on
- Time spent fixing the build if you break the build while working on your card
- Q&A or technical design discussions related to your story card
If it relates to your story card, it's not drag.
Drag is defined as anything extraneous that takes software engineers away from working on a story card:
- "Left field" requests or chores
- Production hotfixes or bugs
- Random sidebars
- Too many meetings
- Unplanned work inserted into the sprint
Here's another example (artistic renderings are optional):
As soon as drag happens, the team member impacted writes a short description of the drag item and an estimate of how many total hours were devoted to drag. The sticky note is put into the drag bucket, and then everyone goes back to writing code.
During the team's retrospective, the team examines the contents of the drag bucket, identifies trends or patterns, and creates action items to get rid of drag.
Ok, We're Tracking Our Drag: Now What?
The obvious advantage of using a Drag Bucket is that the team isn't left trying to remember what happened each day of the sprint at the end of the sprint, during the retro, weeks later from when the actual events occurred. Instead, we have a log of items from each impacted person and his or her estimate on how much time was spent on stuff unrelated to feature development.
No team members were harmed in the documenting of this drag:
Best of all, the Drag Bucket provides the team with tangible, quantified data points. They can now have an informed discussion along the lines of, "Ok - that one curveball out of left field from Thursday last week? That cost us 22 hours collectively as a team. That's almost 4 days of heads-down time. What can we do to make sure that doesn't happen again?"
A Few Last Thoughts
It's just for the short term.
After teams have been tracking drag for two or three sprints, that's usually the point in time when I caution them that the Drag Bucket isn't meant to be a permanent fixture.
The Drag Bucket is a simple diagnostic tool that's lightweight enough that any team can quickly and easily put into practice. If you find that your team is relying on the Drag Bucket sprint after sprint - where the team is consistently producing and/or remediating drag - then chances are high there are deeper, underlying issues the team needs to examine. The Drag Bucket is a meant to be a temporary solution that helps teams get a detailed idea of what's going on.
What isn't the Drag Bucket?
The Drag Bucket is not a replacement for sprint metrics - such as tracking velocity, your burnup or burndown metrics, epic completion rate, etc. As any scrum master can tell you, when it comes to preparing an end-of-sprint report, sprint metrics are in a whole other category unto themselves. Tracking drag merely pinpoints and clarifies the factors that slow down a team's velocity - which is just a small part of the complete picture when it comes to sprint metrics.
A Bucket of Many Shapes.
Lastly, as one of my past teams pointed out to me, maybe you name the Drag Bucket something else entirely.
It might technically be a Drag Envelope.
Or a Drag Bag.
If you have a distributed team, you definitely want to create a virtual board that everyone can contribute to easily.
Whatever your choice, your setup should be simple enough where everyone on the team can track a person's name, the drag they worked on, and total number of hours spent on drag.
Just get yourself any drag receptacle and start logging that drag!
