Get certified - Transform your world of work today

Close

Capacity Planning Is for Busy-ness, Not Business Value

13 July 2017

Stacey Ackerman
Ackerman Consulting Services


Scrum teams, I beg you to stop using capacity planning for sprint planning. Capacity planning is a holdover from Waterfall, and it focuses on one thing and one thing only — individuals. If you want to focus on teamwork, which is what Scrum is all about, please destroy your capacity planning worksheet or tool immediately.

I was coaching a team that had the most elaborate capacity planning spreadsheet I had ever seen; there were mathematical calculations way beyond my brain power. Because everything was so meticulously calculated, their plan must be pretty good, right? Well, it was the furthest thing from that. In fact, it was so well planned that the plan gave the team a false sense of accuracy.

Management was angry because this team never got the work done that they were asking for. The team was on the “red” list, meaning all of their projects were always in trouble.

Once we started focusing the team on teamwork and providing business value, they started delivering the right things, even if everyone was less “busy” on paper.

I also worked with a team that was an Agile powerhouse. This team never assigned work to a specific person. The entire team would work the priority stories from top to bottom collaboratively. They always ended every sprint with the most important work done. While no one could prove that the team was 100% allocated or always busy, management didn’t care. They were getting a ton of value.

These are some of the major challenges I’ve noticed in my coaching experience with capacity planning.
 

Capacity doesn’t equate to productivity

Just because someone is available for 40 hours a week doesn’t mean that they will produce 40 hours’ worth of value to the business. Busy-ness doesn’t equal value. It never has and it never will. Even if you try to compute it differently — such as using an 80% factor to account for “non-productive time” — you still can’t say that allotted time will buy you anything of value. You can have a team planned at 120% capacity that produces a whole lot of nothing.
 

Planning more doesn’t get you more

Capacity planning may look really great on paper, but in reality, it gives you a lot of starting work but not a lot of finishing work. If every developer and tester fills their plate, they will individually be “busy,” but the odds are that stories will only get partially done because the team isn’t focused on completion of meaningful work. They are only focused on their individual pieces, which, alone, don’t provide any value. It takes the collective team to create a working product.

Would the business rather have 10 stories started and everyone is “busy,” or five stories that are done and can provide immediate customer value? The answer seems pretty obvious to me.
 

Capacity planning derails from business goals

Committing as a team to producing business value every sprint is the goal in Scrum. When we get out our fancy Excel spreadsheets or software planning tools to measure capacity, we start to lose sight of our goal. We forget what we are actually trying to accomplish as a team and get sucked into the metrics and proving to managers that we are “busy.” We are not in business to be busy and prove ourselves to managers. We are in business to build something our customers want.
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4 (3 ratings)

Comments

Julian Bayer, CSM, 7/17/2017 4:52:10 AM
So what alternative do you suggest, then?

If my 5-person team usually has an average velocity of 20 points per sprint and one of them is on vacation for the next sprint, forecasting 16 instead of 20 points is just common sense. Sure, it might not be 100% accurate, but it's certainly more accurate than claiming that the team will be able to do just as much work as usual.

Not everything that's been used in waterfall is inherently bad. Capacity planning is good practice. Just don't overdo it. There's no need to write complex formulas as the ones you describe in your examples. There's also no need to account for every single hour in the Sprint. But there certainly is a need to make a realistic forecast of the work likely to be done in the next Sprint. Just keep it to (half) day granularity. Keep it simple.
Tim Baffa, CSM, 7/20/2017 11:15:23 AM
Agree with Julian.

The author seems to equate capacity planning to poor practices such as resource optimization or micromanagement. I unfortunately do not see that connection.

To me, there is indeed benefit to the team to have visibility around their overall capacity each sprint, to help guide their sprint forecast.

Velocity and Capacity are two valuable planning metrics for the Development Team to use. But each metric has the potential to be destructive if used outside of planning purposes, or used outside of the Scrum Team.
Stacey Ackerman, CSP,CSM,CSPO, 7/20/2017 12:05:59 PM
In some situations capacity planning can be useful, but with teams that are new to Scrum, in my experience, it detracts them from looking at the sprint as a team commitment. In more mature team it can be good as a final check/balance, but only if the team doesn't misinterpret individual availability to overcommit to the sprint. Just my opinion, but I appreciate the different perspectives!

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe