April 2009

Monthly Archive

When Is Team Velocity Affected?

Posted by on 07 Apr 2009 | Tagged as: Agile, General, Leadership, Product Owner, Scrum, XP

For some time I have described team velocity as a:

function of (sprint length, team makeup, sizing nomenclature, product)

Given these parameters to team velocity, how can each affect team velocity when modified?

Sprint Length

It is common for teams when they first implement Scrum to have difficulty with short sprint length. They are probably not used to delivering potentially shippable code every 2 weeks or whatever their initial sprint length is. When a team is having difficulties many of them believe that lengthening the sprint length will alleviate the problems. When a team is thinking about doing this, I now share a phrase that I heard from Chet Hendrickson at a technical debt workshop we both attended:

Lower the threshold of pain

Instead of changing the sprint length I want to facilitate teams in identifying what is the root cause of their difficulties. Many times I have found that the problems are either technical or external difficulties. Technical difficulties such as:

  • executing manual testing takes too long
  • not enough support from QA department for testing each sprint
  • build takes too long to validate and deploy
  • too much technical debt

are something that the team can start to work on. A team must work with their Product Owner to understand the technical issues and what they will get in return for fixing the most important ones. External difficulties may come in the form of:

  • sign off takes too long from external person in organization
  • cannot deploy into external environments easily
  • not able to get key people with special skill sets on team

and can cause the team problems in getting to potentially shippable code each sprint. It is my opinion that a team should weaken their Definition of Done and identify impediments to getting as close to potentially shippable code as they had hoped. If it is technical then they must get items in the Product Backlog. If it is external then the ScrumMaster must shepherd the impediments to resolution or make step-wise progress on addressing them. Take care of the impediments and the sprint length will become less of a problem.

Team Makeup

If the team makeup is changed then the velocity will change. There are many factors that cause this to happen:

  • skill set differences
  • bringing new person up to speed
  • reduction in team size
  • personality problems

The most effective Scrum teams that I have witnessed have worked together, at least a core group, for some time. If your organization is having difficulty keeping teams together then there is an organizational impediment that must be addressed. What about the way work flows to the teams causes them to continually get broken up and reconfigured? Organizations that can give work to teams rather than reconfiguring teams to match the work will have more success with Scrum.

Sizing Nomenclature

Although this is part of the function of team velocity, in my experience it is rare that teams modify their sizing nomenclature. Usually this happens when they first start Scrum where they change from duration-based estimation to estimating size and then deriving duration after executing a number of sprints. If the sizing nomenclature is changed from 2n to Fibonacci sequence there could be a significant change in velocity numbers. Fibonacci sequence produces a curve that rises at a much shorter slope than 2n. 2n is used by teams who have significant risk in technology knowledge on the team, such as in using new platform or R&D. The technical knowledge may lessen over time and they might decide to change their sizing nomenclature to Fibonacci instead. This will have an effect but, again, this has been rare in my experience.

Product

It can’t be said enough but:

Team velocity cannot be compared across teams! – Take NOTE managers!

If teams are working on different products, and therefore different Product Backlogs, then they will have to consider different contextual issues when deriving their velocity for planning efforts. Velocity is most useful when all parts of the team velocity function above is staying consistent. Teams should understand this and if they start working on a different product such as:

  • another project
  • new initiative
  • or an actual different product

then they should understand that their team velocity will be affected.

Conclusion

Consider the items described in this article that can affect team velocity usefulness in your own projects. Team velocity is a:

function of (sprint length, team makeup, sizing nomenclature, product)

If any part of this function is modified then it will affect your team velocity. Bring this up amongst the team and management so that it can be discussed honestly and dealt with in a reasonable way.