Get certified - Transform your world of work today


Take the "Complexity" out of Estimation

26 September 2013

Todd Wilson
Sawtooth Agile Inc.

I was coaching a Scrum team through planning when something interesting happened. The team composition had recently changed, and the members had just come out of a Potentially Shippable Increment (PSI) planning meeting the day before. We had implemented SAFe about seven and a half months ago, so we were in our fourth PSI. I had never been in one of this team’s sprint planning meetings. The team has been following the Scrum framework for more than a year and a half and uses Fibonacci for relative sizing. They had just finished tasking a backlog item with a relative size of 21. There were 15 total hours for the tasks. The next backlog item had a relative size of 13. However, when the tasking was omplete and estimate done, the total work effort was more than 200 hours.

Through conversation I learned that the estimation was not based on the amount of work in the backlog item but rather on the complexity of the work in the backlog item. The backlog item with the 21 was more complex than the backlog item with the 13. The obvious problem here is that when estimation is based on complexity alone, predictability tends to go out the window. I would expect this from a new Scrum team, but this team had been estimating for more than a year. What happened?

The team and I had a quick conversation about effort over complexity, similar to what is covered in an article by Mike Cohn ( We got through the concepts very quickly.

I mentioned this to a fellow coach and was a bit shocked at what I heard. The coach explained that we should base our estimates on complexity and then factor in scope to determine the size of the story. I thought to myself, "So this is where the team went sideways."

I feel that Mr. Cohn’s blog is unambiguous and appropriate for 99 percent of the population. However, we may need something else for those who require more in order to diffuse the argument and convince them that adding "complexity" to the conversation does in fact add unnecessary complexity to the conversation. Predictable results require accurate estimation of backlogs; therefore, accurate estimation leads to predictable results. Within every story there is work to be done. A goal of estimation, then, is to predict whether or not the work to be done can fit into a specific timebox.

Force is said to do work when it acts on a body, so that there is displacement (W=Fd). Another way to look at work is the amount of weight lifted through a height. Force is any influence that causes an object to undergo change. Effort is mental or physical energy that is exerted in order to produce work. So effort is essentially a measure of force. Let us use the formula Work = Force * Displacement and then add meaning based on our understanding of software development.

Understanding that backlogs are work to be done, we can then substitute "backlog" for "work" in the above equation. Force (effort) then can be replaced by the energy a development team must exert to complete the backlog. Displacement can be seen as moving a backlog item from "open" to "in progress" to "complete."

We can see, then, that work is development team energy that is exerted in order to move the backlog from one state to another.

Because we use relative size during our estimation, we do not need to think about hours or complexity to decide how "big" a story is. We simply compare the energy we believe it will take to complete a known but unworked backlog with the energy the team exerted on a known and completed backlog.

So where does complexity come in? Complexity is relative to the experience and knowledge of the individual applying the force on an object. If all team members are equally experienced and equally knowledgeable, then complexity is understood and is usually ignored. It's similar to multiplying a number by one. When there are different levels of experience on a team, then understanding complexity as an average can be helpful. This is why Scrum teams effort a backlog item at the same time, using planning poker. If there are differences in opinions, then a conversation is required. The conversation is the great equalizer.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 3.8 (4 ratings)


Ronny Katzenberger, CSM,CSPO, 9/27/2013 2:52:21 PM
minor typo in your last paragraph:
"This is why Scrum teams ESTIMATE a backlog item at the same time..."

Thanks for your article.
Todd Wilson, CSP,CSM,CSPO, 9/27/2013 3:07:40 PM
Yes, Estimate the effort would be appropriate and less ambiguous. Thanks for reading and providing feedback!

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up