Project Management

How to Avoid Overcommitment During Sprint Planning

From the The Reluctant Agilist Blog
by
Adam Weisbart | Agile | Agile 2013 | agile 2014 | agile 2015 | Agile 2017 | Agile 2018 | Agile Alliance | agile coaching | Agile Estimation | Agile for Humans | Agile Metrics | Agile Practice | Agile Teams | agile transformation | Agile Transition | Agile Uprising | agile2014 | agile2015 | agile42 | Agilistocrats | Alistair Cockburn | Atlassian | autism | Bas Vodde | BigVIsible | Bob Tarne | book review | Brian Bozzuto | business agility | carson pierce | Center for Non-Violent Communication | Certification | Certified Scrum Master | Certified Scrum Product Owner | Change | change management | Chet Hendrickson | Chris Li | Christine Converse | Coaching | collaboration | commitment | Communication | conteneo | Craig Larman | cross functional teams | CSM | CSPO | DAD | Daniel Gullo | Dave Prior | David Anderson | David Bernstein | David Bland | David J Anderson | derek huether | Dhaval Panchal | diana larsen | Digital Agency | Digital PM | digitalpm | Disciplined Agile | Disciplined Agile Delivery | Distributed Teams | Don Kim | dpm | dpm2013 | drunken PM | drunken pm radio | drunkenpm | drunkenpm radio | eduscrum | emotional intelligence | empathy | Enterprise Agile | Essential Scrum | esther derby | Excella | Fixing Your Scrum | Gangplank | Gil Broza | Howard Sublett | Individuals and Interactions | Jean Tabaka | Jeff Sutherland | Jesse Fewell | Jessie Shternshus | jim benson | johanna rothman | john miller | Jukka Lindstrom | Jutta Eckstein | kanban | Kanban Pad | kanbanfor1 | Ken Rubin | Kenny Rubin | Kim Brainard | lacey | Language | Large Scale Scrum | Larry Maccherone | Leadership | LeadingAgile | lean | Lean Coffee | Lean Kanban North America | LeanKit | LESS | lkna | luke hohmann | lyssa adkins | Maria Matarelli | Mark Kilby | Marshall Rosenberg | Melissa Boggs | Michael Sahota | Mike Vizdos | Modern Management Methods | modus cooperandi | Modus Institute | Natalie Warnert | Nic Sementa | Non-violent communication | North American Global Scrum Gathering | NVC | Olaf Lewitz | ├średev | ├średev 2013 | organizational agility | Organizational Change | overcommitment | Patrice Colancecco Embry | Paul Hammond | personal kanban | personal productivity | personal project management | Peter Saddington | PMBOK | PMI | PMP | podcast | portfolio management | Product Backlog | Product Development | Product Goal | Product Owner | Product Ownership | productivity | project management | Project Management Institute | ProKanban | Rally | Release Planning | reluctant agilist | Renata Lerch | retrospective | Richard Cheng | Roman Pichler | Ron Jeffries | Ross Beurmann | Ryan Ripley | SAFE | Safety | Sallyann Freudenberg | scaling agile | Scaling Scrum | Scott Ambler | Scrum | Scrum Alliance | Scrum Gathering | Scrum Master | ScrumMaster | self organizing teams | SGPHX | SGPHX 2015 | Shane Hastie | social engineering | SolutionsIQ | SoundNotes | SparkPlug Agility | sprint planning | Systems Thinking | Team | teams | Temenos | The Improv Effect | Things | Tom Perry | Transformation | Troy Lightfoot | troy magennis | User Stories | value | Vivek Angiras | waste | Waterfall | Weisbart | What We Say Matters | why limit wip | WIP | women in agile | Woody Zuill | show all posts

About this Blog

RSS

Recent Posts

Lead Without Blame with Tricia Broderick

In Defense of Frederick Taylor with Christine Li

Story Points are Good AND Evil with Ryan Ripley

Value Stream Management with Derek Huether

Improving Value Delivery In Your Organization with Gil Broza



Awhile back I was working on an Agile coaching gig with Tom Smallwood. We were working with a team that moving to Scrum and was having a particularly difficult time meeting their commitments.  Stories were being estimated in Story Points using the Fibonacci sequence and they were breaking stories down into tasks that were then estimated in ideal engineering hours. Stories were (mostly) small enough to go from card on wall to potentially shippable in about 2 days. Tasks were kept to between 4 and 12 hours. Unfortunately, despite following the basic guidelines we were giving them, they were still WAY over committing each Sprint.

Tom was the first one to notice that even though they were all confident in their ability to get the work done at the end of a Sprint Planning meeting, what they were confident about was in fact, completely impossible. What was happening was that each person was assumed to have a capacity of 8 ideal engineering hours per day. Since we were working in two-week iterations, this meant each person was on the hook for 80 hours of productive working time in a Sprint. 

 

The way we addressed this initially was to ask them to plan for no more than 6 productive working hours per person each day. This helped, but it still wasn't cutting it. The problem was that each person had more that they were responsible for than just the project we were working on. (Yes, this is not ideal, but it was reality at the time.)

 

The solution we came up with was very simple and it is one I have used on every team I worked with since. It adds an extra step to the Sprint Planning ceremony, but it has been invaluable in helping teams understand their capacity and preventing over commitment. 

 

(Disclaimer - this involves using relative Story Point Estimation for Stories and Ideal Engineering Hours for Tasks. There are many who do things differently and have great success - which is awesome... what follows is just what I have found to work well for me and the teams I've worked with.)

 

What we added was a step in the 2nd half of Sprint Planning. After the team has taken the User Stories (estimated in Story Points) and broken them down into Tasks (estimated in Ideal Engineering Hours), we would go around the circle and ask each team member to estimate how many ideal engineering hours he/she could commit to being responsible for in the upcoming Sprint. One of the most critical parts of this is the idea that the commitment being made is not to the PO, but to the other members of the development/engineering team. So, if I tell my team I'm good for 35 hours, then my team can count on me to be responsible for 35 hours of task work. If I commit to that and do not contribute that amount of time, my team members will have to cover for the work I've not done. While this should go without saying, I have found it to be helpful to mention when starting this part of Sprint Planning. 

 

So, going around the circle, each team member has to be aware of how much time they can commit to contributing. This means they need to account for a lot of the things that get in their way.  

 

Here is how I normally coach people to think through this:

 

In a two-week iteration, you begin with 10 working days. However, I normally block out 1 day for Sprint Planning, 1 day for the Sprint Review and Sprint Retrospective, 1/4 day for the 8 remaining days during which the team will hold a 15 minute daily standup and 1/4 day for an Estimation/Story Meeting. While blocking out 1 whole day for Sprint Planning and 1 whole day for the Sprint Review and Sprint Retrospective meetings is more than the Scrum Guide calls for, I have found that it is more realistic to working under the assumption that the team will get little else done on those days. 

 

If the Sprint is 2 weeks long, we start with 10 working days. Once we block out the time mentioned above, we end up at 7.5 working days.

 

If we assume each person can be productive for a maximum of 6 hours per day, then:

 6 hours/day * 7.5 days = 45 

So, the absolute Maximum Possible Productive Hours (MPPH) for any individual in a two- week Sprint is 45 hours. 

 

We then ask each person to total up the amount of time they expect to lose during the upcoming Sprint to the following events that are not part of the Scrum Framework:

 

  • Standing Meetings  - recurring meetings held each week that will keep them from working on the project
  • Holiday/PTO - expected
  • Vacation/Sick time - expected or averaged
  • Medical/Dental/Other Personal Appointments - expected or averaged
  • Emergency Fixes* - average time lost per Sprint to emergencies which require them to temporarily abandon their work on the project
  • Misc. Additional Time - Any additional time they feel they should block out to address other issues, work or personal, which will inhibit their ability to contribute to the project during the Sprint

* Getting pulled away from a project to deal with emergencies that are not related to the project is a dysfunction that will impair the team's ability to realize the full benefits of Scrum. However, in several organizations I have worked with, it is a constant reality. When things break, and the money stops flowing, it's all hands on deck.

 

The total of the above is the Interruption Time (IT) that each team member must subtract from his or her   MPPH. The amount of time left is the Revised Maximum Possible Productive Hours (RMPH).

 

If the individual is only working on a single project, then the RMPH is the amount of time that individual should feel comfortable sharing with their team members as their Committable Productive Time (CPT). 

 

If the individual is split on multiple projects, then they should multiply the percentage of their time that is allocated to the project by the RMPH. They should then subtract an additional 10% from the result (for context switching) to get their Committable Productive Time (CPT).

 

Here is an example of the above...

 

Interruption Time:

  • 4 hours standing meetings
  • 8 hours PTO
  • 3 hours for dentist appointment
  • 5 hours average time lost to Emergency Fixes
  • 5 hours subtracted because I will just be returning from overseas and I expect the jet lag to have a negative impact on my productivity for a few days

Interruption Time (IT) = 25 hours

 

45 (MPPH)

- 25 (IT)

20 (RMPH) 

 

If I am split across 2 projects at 50% each...

 

20 (RMPH)

*50% allocation

10 hours

-10% (context switching)

9 hours of Committable Productive Time

 

In talking through this, it is very common to see jaws drop. However, if each person on the team is doing this, then the team will have a realistic understanding of its' work capacity in a given Sprint. While the idea of having to tell someone responsible for your performance review that in a two-week period that you can only be counted on for 9 hours of time may be scary, it is honest. If we are practicing Scrum and sticking with transparency (one of the 3 legs of Scrum), and we are being responsible to our fellow team members, this is the most responsible, transparent thing we can do. 

 

Once each team member has shared their CPT, they are totaled up and this is the Team's Committable Productive Time (TCPT). As long as the total number of estimated ideal task hours does not exceed the TCPT, then the team should feel comfortable making a commitment to the Product Owner for the Stories they will complete during the Sprint. If the number of estimated ideal task hours does exceed the TCPT, then the team may have to negotiate with the Product Owner to reduce the work being planned for the Sprint before they make a commitment. 

 

I have also seen teams break things down even further into number of hours for development, testing, etc., but what is above is typically as deep as I go with it.

 

It adds an extra step, but it helps the team members inspect and adapt their own workload and capacity. This will also better enable them to meet their commitment in a Sprint; IMHO, the benefits of this far exceed the few extra minutes it will take for a team to make sure they are not overcommitting. 

 

 

 

 

Posted on: October 28, 2012 01:28 AM | Permalink

Comments (4)

Please login or join to subscribe to this item
Anonymous
While I found this interesting and true in order to be realistic when planning does it really work for the team and the company? Does this cause the team to "undercommit"? I guess it would depend on how good the team is at estimating the size of their stories to begin with.

Anonymous
Though I am not an expert on Scrum and its working, but i too feel that this granular level of finding the total commited time is asking too much from a team member. Mostly they have a different maturity level and each of them have a different view on their task completion. So commitment to hours instead of commitment to work will lead to a short fuse atmosphere, where they will only be considered about their work completion and cutting of corners for any improvement on the existing work.

Anonymous
Thanks for your comment Doris. I actually found that it helped prevent the team from under-committing. Because it allowed them to have a better understanding of what they truly expected their capacity to be. It allowed them to make sure they had enough, but not too much in their commitment.

Anonymous
Anju - Thanks for the feedback. In what I described above, the commit is to potentially shippable work. The whole approach to understanding their hours is meant as a safeguard they can use to protect themselves from making a commitment they cannot meet. I would also say that if the team feels so pressed to deliver that they are cutting corners and letting the quality suffer, then there are larger issues that need to be addressed.

Please Login/Register to leave a comment.

ADVERTISEMENTS

"Bad artists copy. Good artists steal."

- Pablo Picasso

ADVERTISEMENT

Sponsors