Your browser does not support JavaScript!
  • LinkedIn
  • YouTube
  • RSS

Developers are regularly faced with the conundrum of cramming 10 tons of work into a 5 ton bag. The latest version of this appeared on the Scrum Development list today.

  • We have a 1500 point project.
  • We have a 9 person team.
  • We have an estimated velocity of 70 points a sprint.
  • The team can get the project done in 22 sprints.
  • If we're doing 2-week sprints, the team can get the project completed in 10 to 11 months.
  • But we have a "Date+Feature-Driven" project. We must have the features for this project completed in 8 months.

Putnam has done an analysis of 491 medium size projects to see what effect team size has on project completion date. He shows that a 5-7 person team can get a project done in 11 months that will take a 9-11 person team over 16 months. This shows that adding people to the team will delay the project.

You must go to multiple teams. How easy is it to divide features or components up and give them to relatively independent teams? Let's take your 9 person team and add five people to get two teams of 7 people. Could doing two 8 month projects with teams of seven add up to one 11 month project with a team of 9?

Adding five new people now will slow things down. An easy way to factor this into planning is to assume the five new people start at a productivity of 0% and ramp up to 100% productivity in 6 months. I would conservatively assume that 5 new people will give you an effective 2.5 new people over the eight month period.

In order to get 1500 points done in 8 months instead of eleven, the combined teams must be able do 2062 in 11 months. That means that two teams of seven must run at a rate that they would each get 1031 points done in 11 months. If you take 2 people off the current team to get a 7 person team, that team should be able to run at the 1031 point velocity.

The question is, can a new team of 2 experienced people plus 5 new people run at that velocity. No! You are in the terrible grip of the conundrum.

Here is where the ScrumMaster (now a Scrum of Scrums Master) needs to suck it up and take some risk based on real world experience. I would want two fully functional teams of 7 people each. I don't want three teams and I don't want them to be more than 7 in size. Ask for five people and hire up. Make sure they are even better than the average of the people you have on board. When you can't hire them fast enough, bring in an experienced ScrumMaster consultant to take one of the teams for you.

When management is outraged by the size of the request, show them Putnam's chart. It says 14 people take longer to get the project done than 9. It is only through the ScrumMaster's skill and cunning that they can cut through this conundrum with 5 more people.

en_USEnglish
Shares