Agile‎ > ‎

Moving from Individuals and Time to Points and Velocity

posted Aug 26, 2015, 12:45 PM by Anjuan Simmons   [ updated Jul 21, 2016, 4:40 PM ]
I've been in meetings with many CIOs where the CEO demands to know when features will be done. CIOs inevitably resort to framing their answer in terms of individuals and time. This is fine in a waterfall environment, but this framing is often done on Scrum projects. I usually (in private) coach the CIO in a discussion or email that goes like this:

I wanted to share with you my thoughts about communicating to upper management when things will be done. During the last meeting I attended that included you and the CEO, this exchange happened several times:

CEO: When will this feature be done?

YOU: It will take one developer # weeks.

I think that communicating timelines to the CEO in terms of individuals and time estimates is, while common, sub-optimal. This is based on two theories:
  1. Finishing a feature takes more than the skills of a developer. Getting a feature to Done requires QA and often design resources. That's why Scrum uses story points to size features according to the Definition of Done which includes all of the work needed to get a feature to Done.
  2. Humans are bad at making time estimates even when using concepts like "ideal days". Also, upper managers tend to "do the math" with time estimates by trying to do calculations based on number of developers and how many days of work they get get out of a sprint. That's why Scrum uses velocity (a dimensionless value) as a measure of what the team can get done in a sprint.
So, based on these two theories, exchanges with the CEO would go like this:

CEO: When will this feature be done?

YOU: That feature is, relative to similar features we've done in the past, # points. The team has a velocity of X, so, if the team only worked on that one feature, it would take Y sprint(s).

By doing it this way, you give our CEO an estimate based on everything needed to truly finish a feature. Of course, it's even better if the size communicated to her comes from the team that will do the work. However, I know the investment of time required for team estimating may not be possible before giving an estimate to our CEO.

This exchange has to be done in the context of the team assigned to any given project. It is natural for velocities to vary widely between Scrum teams.

Of course, there is no way of communicating estimated times to complete that cannot be gamed or questioned by a CEO. However, I think that using points and velocity gives the CEO what she wants with a reasonable degree of accuracy.