Monday, June 09, 2008

Scrum & Overtime?

Does Scrum have any rules about overtime?

Recently, the Quality of Life issue has been revived. This is a good thing to talk about regularly and I applaud Erin Hoffman, Jason Della Rocca and others for not letting this topic die. A recent Gamasutra article discusses how things have progressed since the EA Spouse days of 2004. It doesn't sound like much has improved.

I've heard people say that Scrum avoids overtime because teams can decide to drop some of their Sprint goals if they are faced with too much to do within 40 hour weeks. I disagree with this interpretation. I think it creates problems.

Teams commit to a certain amount of work that they estimate can be completed in a 2-4 week Sprint. Estimating 2-4 weeks worth of work can still have uncertainties though. There can be many unanticipated problems that can occur during the Sprint that can impact progress. But this doesn't mean the team can or should dump goals at the first sign of trouble.

Teams should take commitments seriously. This creates a pressure on them to find more effective ways to work to meet commitments. We want the teams constantly looking for small improvements. Even a 1% improvement each Sprint will add up big in the long term.

Don't Punish Overcommitment

Sometimes a team will push too aggressively on their goals or hit major problems that they couldn't anticipate or were out of their control. If we insist that they complete all their goals even if they have to work insane hours, they will not continue to push the limit on future sprints. They will sandbag to avoid the pain. Teams should know when there is too much to do in a reasonable amount of time and should go to the product owner to discuss dropping some goals when there is too much to do.

So how much overtime should a Scrum team do? It's up to them. If it's the last Sprint before a major release we'll see teams putting in a couple of weeks of late nights and rarely a weekend. If they find that they are doing this too often, they need to improve how they estimate.

One thing for sure is that when management doesn't dictate overtime to the teams, the attitude about overtime changes. When a team decides to do overtime, they do it as a team. They help each other out. It can actually be a strong team building experience.

"Sustainable Pace"

Teams should find a sustainable pace that they can work over the long term. This might mean working close to 40 hours per week most of the time with periods of crunch that don't last too long.

How long should crunch last? There have been studies that show the real effectiveness of crunch. For us, the proof came the last time management enforced company wide overtime (in 2005). We "asked" the teams to work 6 days a week at 10 hours a day to finish Darkwatch. The proof came from the velocity observed in burndown charts.

The following chart shows how much time the teams averaged in burning off their estimated hours per week:

The first week was a normal ~ 40 hour week. Weeks 2-5 were the 60 hour weeks. The first thing you notice is that the overtime in week 2 caused the velocity to greatly increase. More "stuff" was getting done! However the velocity decreased until we get to week 5 where the velocity was even less than a normal week!

How is this possible? It's simple. People get tired. They make more mistakes. They lose the incentive to create value.

This is what I love about creates simple empirical evidence about what works and what doesn't. This is why there is no "rule" about overtime in Scrum. There doesn't need to be a rule. If your teams are truly using Scrum to find the best way to work, they'll quickly discover that after several weeks of moderate overtime, the value is lost and you might as well not continue. It becomes common sense.


Jamie said...

Sorry, been a while since I've caught up on the blog, so I'm coming late to the party here.

I'd want to see more weeks of data prior to the crunch - because in my experience velocity tends to trend down over time anyhow, I'd want to know if I was looking at a constant velocity which then spiked with crunch and fell off afterwards, or if velocity was already trending downwards, and crunching therefore was really "adding a constant" every week.

More importantly, I'd like to see the double baseline - did you take away the crunch, and when you did, did velocity return to normal levels?

Clinton Keith said...

>in my experience velocity tends to trend down over time

That's the opposite of what I've seen Jamie. Teams tend to get more effective over time. They improve how they work, they learn how to work better with the technology, etc.

Over longer terms, you use story point estimates to compare, but you can only really compare releases against one another. Story points accomplished per Sprint are variable.

Jamie said...

It's true, I am talking about the long term / story point velocity rather than the velocity over the sprint.

So you're saying velocity over the sprint did come back to normal levels - and started trending upwards - when you took away the crunch? That is what I want to hear.

Clinton Keith said...

>I am talking about the long term / story point velocity

Both improve over time. It's a bit hard to imagine one improving and the other getting worse! ;)

>So you're saying velocity over the >sprint did come back to normal >levels

No. The crunch ended with the Sprint. It did return to normal (hours of accomplished work per calendar day) the following Sprint.

Jamie said...

Great news about the double-baseline.

For the other thing, I guess you're defining velocity as (delta in work done)/(time) whereas I'm defining it as (delta in work remaining to be done)/(time) - so for me scope increases show up as diminished velocity, and although sprints might have fairly predictable velocity (because you don't allow scope increases during a sprint), for the release or project I see a continual drag as ballooning numbers of "must do" items are added to the backlog.
So, it may be hard to imagine, but I'm up to the challenge!

Clinton Keith said...

Hi Jamie,

Using Mike Cohn's definitions...

What you are defining for the release (work done - added scope)/sprint is what is "Net Progress". Velocity per Sprint is the work accomplished in Sprint which is then used to forecast what can be accomplished for the remainder or the release or in future releases.

Coincidentally, Mike posted about Release burndowns today. Interesting article...

Kevin E. Schlabach said...

I just blogged about this great presentation yesterday. It's also from the game industry and related to sustainable pace and productivity.

Kevin E. Schlabach
Agile Commentary Blog