Undercomittment in Scrum

Question

I have a team of 5 developers working a 10 day sprint schedule. After I deduct the scrum meeting times from their total capacity (300 hrs) I end up with 247.5 hrs.

The breakdown is -

Total - planning - daily scrum * 10 - review - retrospective - backlog grooming

300(5*6*10) - 10 - 12.5 - 5 - 5 - 20

The velocity is currently 25pts/sprint.

However, when the team goes in to the second half of sprint planning, they almost always end up with about 80-85 hours of work planned. That equates to about 35% commitment.

Obviously there are a few possibilities here. Either the team is severely underestimating task hours or there is a lot of hidden work getting in to the sprint or parkinsons law is coming in to effect, and the work is expanding to fill the time allotted. My gut feeling tells me it's all three.

My question really is if the team finds that they are under-committed in the second part of sprint planning, what is a good course of action?

• Call the Product Owner back in and take on more work?
• Revisit the task estimates, perhaps using a 3 point method to weed out the critical path?
• Track actuals and make hidden work obvious so we know where the time goes?
• Something else?

I'm not keen on my first 3 suggestions so the 'Something else' is perhaps what I'm looking for. Any advice would be super helpful.

Thanks in advance.

EDIT: I asked this years ago. I was very naive. Don't do this kind of thing,..Ever. Leaving here for others to laugh at :-)

Answer 1

The biggest problem that you are facing is that your team is (on purpose or in ignorance) obscuring their work, and hiding what they are doing. You need to improve visibility.

You say always, so I take it that you have some statistics.

Assuming that your team isn't spending the remainder of their capacity being unproductive (working on unplanned tasks, browsing social media sites, daydreaming), it seems that your team is under-planning. If this is the case, you should work to expose the unplanned tasks that are being carried out, and then add them, account for them, or if necessary, have the team stop doing them.

On the other hand, it is possible that your team is purposefully being unproductive, and there is no easy way to handle that. If this is what you are facing, I'd try to figure out why this is happening. Perhaps they are feeling overwhelmed and need an outlet, or they feel that they are doomed regardless of the effort and might as well have fun. This needs to be approached very delicately, though possibly quite forcefully, if nothing changes their mind.

The important thing to remember, is that the numbers and accounting are not the problem - they are only the symptom and indicator of a deeper one, which the Scrum Master should strive to solve.

Answer 2

I was pretty much in the same boat a few years back, except we would often end up with overcommitment instead, essentially due to the fractal nature of estimates.

In my current team we decided to take a different approach and just rely on Story Points and velocity to determine sprint commitment. We do break down stories into tasks and give tasks a rough man hours estimate, however we do it essentially as a pretext for discussion/exploration and to lift technical uncertainties. We don't try to sum up estimates and relate it to planned velocity in any way afterwards.

What we do as a team to prevent the (theoretical) Parkinson effect you describe is we always set ourselves an ambitious goal for the coming sprint. This typically means taking one or two "bonus" user stories more than what our velocity would typically allow us to do. This way we're always pushing things forward, challenging ourselves and, even assuming we at some point had a 35% commitment (which I'm not sure how you'd arrive at), the gap would quickly be filled to attain full team speed.

Through that experience, I came to the realization that not tracking task times (especially not getting into complex calculations involving Scrum ceremony times, external activities or meeting durations) and not living under the constant fear of failing to "correctly estimate" is liberating - it allows you to concentrate on what's really important : delivering business value. Shipping quality features is the first priority. Estimating is only a byproduct. Let average velocity be your guide to determine the rough amount of work you can commit to. Embrace potential failure, you'll never get it exactly right anyway.

With starting velocities being equal, I'd pick a team that is bad at estimating because of its surprising repeated productivity improvements over a team that is only improving its estimates (even eventually getting them close to perfectness) any day.

Answer 3

For our new team, we "forced" them to plan for the total number of available hours. I didn't force them to add hours to stories, we just took on more stories since there was more time left (and how do you justify to your PO what they will be doing for the other remaining hours?). We did however tell the PO about this strategy and that they wouldn't succeed.

So of course, they end up over-commiting the first few sprints. But then, they realize they need to estimate tasks much better. It took about 3 sprints to get much closer to the reality. Each retrospective was focused on finding out where stories were being underestimated (wrong tasks, missing tasks, underestimated tasks, unknown, etc.). From sprint to sprint, I could see the tasks being refined.

Answer 4

Sprint Capacity Planning consists of more than simply subtracting meetings from the Sprint duration. I usually use this calculation:

For a 2 week sprint, consider that you have only 9 working days (one day is lost to Scrum meetings). Multiply this number by the number of people on the team (let's say 7 in my example). So we now have 63 days.

For each person, subtract planned time out of the office (holidays, medical appointments, off-site meetings etc). Let's assume that we have no planned absences. So we still have 63 days.

For each person, consider that they can only be "In the zone" (ie: coding) for a certain number of hours per day. For a new team, I'll use 4 hours per day for the calculation. So we now have 4 * 63 = 252 hours. Compare this to the more simple 63 man days * 8 hours per day = 504 hours and you can see it's almost half.

Finally, I apply a 'mitigation factor' to allow for those distractions that always happen. I subtract 10%. So now, we have 227 hours and that's what we use for planning purposes.

The calculation is not massively scientific but, it seems to work out most of the time.

One final thing. I only use Sprint Capacity Planning when the team are new. Once we have an established velocity, we use that instead. It's faster and usually more accurate.