if(effort -neq time){velocity -eq effort\time}

I have been doing Scrum for years and have had some great teachers (Richard Hundhausen, Derek Davidson and even Jeff Sutherland - well, I read his book :-)) but one very important aspect of of the framework has continued to haunt me until now.

I have always struggled to explain the difference between effort and work required and no matter how many times I suggested that effort was related to complexity I was never able to come up with an analogy or explanation that would suffice. The team would constantly revert to the assumption that effort meant how much of the sprint (therefore time) would be needed to complete the work; I would say, "no, that is what we use work remaining for" and the team would invariably reply "what's the point of effort then?".

The other day while explaining the importance of doing design in the planning meeting to a bunch of colleagues, one very astute colleague asked the question "won't we run out of time in the planning if we are getting into the detail of design in the meeting?". I realized that I had not explained the point of estimating effort for each backlog item and then it suddenly dawned on me...what does effort actually mean? Here is the quick google definition:

Ahha! Given that effort is about how much energy or determination is required to complete something, then it must be dependent on the amount of complexity and unknowns contained within the change; and the time it will take is dependent on the tasks required to complete it.

But the thing is we only know what tasks are involved (and therefore the work hours involved) after we have done planning (if we do it right) and by then we will have dealt with the complexity and unknowns through the design discussions had during planning.

So, it becomes obvious that the estimation of effort should only be used to determine what changes to attempt during planning. Once planning is done it is all down to the time estimated for each task to determine if team has the capacity to complete the planned work.

If the team has estimated poorly, planning will bring it to light and if you don't plan properly the sprint will bring it to light. So if your team is constantly violating the burn down it can only be a result of poor planning.

"Simples Sergei!"