When it’s No Longer Relative

This is a guest blog post by my colleague: Chris Waggoner. Enjoy!

Estimation of time and effort until you’re done is one of those things that every inquiring manager wants to know. In an effort to provide “accurate” estimates, companies and people spend countless hours generating list of task and debating the duration of each task. When it comes to developing software these estimates are rarely correct and often grossly wrong. The estimates are wrong because in building software that we are often building something that has never been built before. When we find ourselves being pressured to estimate something we’ve never done we tend to SWAG (PMI for Sophisticated Wild Ass Guess) the answer in man-days and/or hours without understanding or knowing all the potential variables in play. Here in lies the problem with traditional software estimation methodologies: within a short amount of time spent there are diminishing returns on effort versus value. That is to say, early in the traditional process the value of spending more time estimating doesn’t provide a higher certainty of when we will be done.

In the agile world we are always looking for ways to reduce and prevent waste. One area of waste we focus on is estimation. We want to reduce the time spent on the diminishing returns of effort versus value in traditional software estimation. In agile we do this using relative estimation or relative sizing. Relative sizing is simple for us primates because our brains come prewired with the ability to do it accurately. We easily see small banana, medium banana, large banana and finally extra-large banana. We quickly size and sort eggs, post-it notes, boats, and an almost unlimited number of things we come in contact with in our daily life. We can also size and sort abstract things such as small problem I can handle now, medium problem I need help with, and large problem I have no clue how begin to resolve. The hard wired human ability to size and sort is at the heart of agile relative estimation techniques.

When we train teams on relative sizing we ask them to size and sort their software requirements (or stories) within their backlog. These teams may use something as simple as T-Shirt sizing S, M, L, XL or they may use a more sophisticated Fibonacci scale 1,2,3,5,8,13 . . . With stories in their backlog sized we take them into sprint planning. At some point during sprint planning training we explain the importance of the commitment, number of stories or story points they are committing to complete this sprint, and then ask them to commit. It is normal at this point for a new team to fall silent. Since they’ve never sprinted before they have no clue how many points they should commit to. To help them with their first commitment we use a training approach. Part one of the approach is for the team to calculate their capacity:

• Each team member determines how many hours of capacity they have available during the sprint
• Total gross team capacity is summed by adding up individual availabilities
• The team determines how much slack they need in sprint capacity, normally 20%-30% for
• administrative work and other non-sprint related activities.
• Available team capacity = Gross team capacity - Slack

Part two of the training approach is to fit committed stories within available capacity:

• Team task out stories
• Team estimates hours per task
• Team totals number of hours per story
• Teams add stories to their commitment until their available capacity is full
• Teams commit to story points that sum to their level of available capacity

Did you notice what we just did?

We just created waste in estimating. We left behind the basic principle of Relative Sizing. We asked for a SWAG on the task created. We just sent this new team down the slippery slope of adopting bad estimation habits. We have invited and enabled any manager watching the training process to hold teams to an hourly estimate. Our estimates are No Longer Relative!

This training approach, in my experience, seems to be universal among trainers, coaches and scrum masters and here’s the problem: We don’t tell teams that this is a temporary tool designed to help them learn how to commit until they’ve found their velocity after 5 to 6 sprints. We don’t take this tool away we just leave it there for the team to incorporate into their culture. We don’t take the time to explain that we are purposely breaking a relative sizing, why we’re breaking the relative sizing, and why it’s not a good idea to continue breaking relative sizing. We just leave it there and let it fester into dysfunctional behaviors.

Perhaps you’ve run across some of these behaviors? Consider some common things that I hear when working on this issue with teams:

• Team Member: “We assign 2 hours to every task.” - Team has unconsciously realized that the hours are meaningless. They are just putting hours on task because they were told to.
• Product Owner: “The hourly burn-down chart is how I know if the team will complete the sprint” – The hours are false, they were SWAG-ed; therefore the burn-down is false. Ever notice how hourly burn-downs take a nose dive on the last day of the sprint? The only burn-down chart that has any real consistent value is a story burn-down chart. What value do estimated hours provide if stories aren’t done? Yeah but Cohn’s examples . . . fast forward to Cohn said he could have been wrong in Phoenix.
• Team: “We should get credit for the hours we completed even though the story is not done.” - I’ve found that this discussion leads to hourly estimation driving a misunderstanding of velocity.
• Manager: “Every day the team needs to adjust their hourly task estimates to reflect reality.” - Really? How much waste can a manager create? To what purpose are we readjusting and reconciling hours estimated versus actual hours?
• Inexperienced Scrum Master: “We assign story points to a story during sprint planning based on the number of hours tasked with the story. We have a sizing chart posted in our team room based upon a sliding hours estimated scale.” - I fell out of my chair when I heard this one.

I’ve quit using this training approach because of the dysfunctional behavior it creates. The approach is No Longer Relative. I don’t want any manager within ear shot to hear the words hourly estimate. I’ve even gone as far as to tell a team to task stories only if it helps them accomplish their work. Tasking is a good idea because it helps teams organize. I suggest it but don’t prescribe it. I let the team decide if it helps them or not.

Velocity is going to be what velocity is going to be so let the first time scrum team pull a commitment number out of thin air. Tell them we’re not going to take your commitment seriously until sprint 5 or 6. Don’t ask then to put hours on task. If you do you will no longer be relative.

Chris Waggoner, CSC