The Agile Wilderness: Estimation

About 2 years ago I trained a part of my organization about agile foundations. The team was one of the only remaining teams following traditional waterfall with some scrum practices like stand ups mixed in. The training focused on the agile manifesto, principles, and a general overview of some processes normally followed at the organization. After the training, there was continued discussions about implementing some the practices discussed. Specifically, there was a time when someone acting as the scrum master starting to estimate their work in story points. Once they had estimated their project scope, they set a timeline without a velocity established as a team. This caused them to really just convert story points back to days/ weeks estimates and turned out to significantly overestimated the work for the team. Luckily, we found this misuse of story points quickly. Throughout this article, we will dsicuss the dangers and proper use of estimated.

In this article I will cover:

• Agile principles that apply to estimation
• Methods to estimate
• How not to use estimates
• How to use estimates

There are so many agile practices out there that started based on agile principles. Sadly, many times agile practices are implemented without the mindset behind it and can hurt teams in the end.

Before we get into the agile principles that apply, let's talk about the elephant in the room. There has been a movement over the last few years called #noEstimates. As mentioned in the article from serious scrum "the logic of #noestimate" (1) there are good reasons to stop doing estimates such as misuse or the ability to support other funding options such as drip funding. In some smaller organizations these practices work and are likely simpler and easier. From my experience in larger organizations that are required to report out financials these practices have not been possible or successful.

Agile Principles that apply to estimation

The list of agile principles in picture form are shown below from medium.com. (2)

There are 3 main principles that apply to doing estimates and why estimates can help us meet these goals if used properly:

Principle #1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. (3).

To determine the order of backlog items, we need to know relative the size of getting each item accomplished. Running through a value optimization exercise (shown to the right) is a tool that can be used throughout a product lifecycle. Assuming our team cost remains the same, with focus on the items with a higher value to effort ratio we can help deliver more value quicker. You will notice the graph is exponential. This is because as a feature is completed earlier the value from learning and to customers is recognized sooner and grows over time.

Principle #7: Working software is the primary measure of progress. (3)

A key component of using estimates properly is making sure you have historical data. We are terrible at estimating (4) and therefore it is important to look back at what a "5" took us to get to "done" rather than what we thought. While estimating we always miss out on things required even if we have done them before. This is another reason we use relative estimates rather than exact estimates and only use estimates for forecasting based on historical data.

Principle 8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. (3)

Although many developers complain about estimating work, the end goal is to make sure we can maintain a pace for the team that is sustainable. Sadly, in many cases estimates are used to push teams to extremes instead of allowing the team the time they need to accomplish the task at hand with the proper quality. This does not mean we stop estimating but rather make sure we are more conscious about how we use estimates. It is important that a team knows their pace especially in larger organizations as many teams are dependent on each other and need to understand impacts across teams. We may need to change the order of work based on something else going on in the organization. At the end of the day we need to work together to help deliver the most value and cause the least disruption across the organization.

The agile principles need to remain at top of our minds while doing and using estimation and should be discussed with the team and the stakeholders involved.

Methods to estimate

There are many methods to estimate, and we will not cover them all below but instead show the spectrum of ways to estimate. As discussed above, all my experience comes from larger organizations that require a general forecast for financial reporting. 

Dev Hours/ Days

Most people start with the simplest method using hours or days of dev time. Using this method is highly inaccurate and even after applying confidence % and risk to the numbers they are like pulling a rabbit out of a hat. Another downfall from this can be calculating QA or other roles hours based on dev hours. This further lowers the confidence level as we are really just guessing again here.

With that said, when a team is just starting out this is really all we have as we do not have historical data. We have to start somewhere, and it is as good as any. Make sure to be clear when sharing this information, the assumptions, risks, and timeline in which you got these estimates and understand what the estimates are going to be used for.

Story Points

The Story Points method is the most common from my experience. This method was invented by Chet Hendrickson along with extreme programming however in recent conversations with him he regrets creating it and says it should "not be used". Although there are many pitfalls with how these estimates are used, which we will discuss in later sections, the theory behind story points is solid. Using a relative scale allows us to account for complexity, risk, repetition and compare historical work to upcoming work. Each team will find a grove of what makes sense to them and applies to them as a team. The conversation when estimating should always tie back to historical data and think through if the new story is larger or smaller than others. The most common form of story point is to use the Fibonacci scale (1,2,3,5,8,13,21) as this forces you to understand that there is exponential growth as complexity increases. See below a general idea of the way the scale works. (5) Other similar methods to this are things like T-shirt sizes or even objects however these are more difficult to use as they cannot be added together without a conversion and makes them less useful. 

Item Count

As mentioned above there are some estimation methods that are part of the #noestimates movement. Specifically, the item count method is a way for an agile team to estimate the amount of work they can do without putting a separate estimate on each ticket. The goal of a mature agile team is to break down stories into small chunks that are approxiately the same size, able to be done within a sprint, andindependent from other work. This is difficult for many teams and takes time to learn how best to break down stories properly for the team. This method allows you to have a "velocity" as a team and can therefore be used to forecast out work in the backlog assuming it has been broken down to the appropriate level. 

How not to use estimates

Many teams including I have made mistakes and misused estimates. Some of the common misuses are converting them into dev hours, comparing velocity across teams, and packing sprints full.

Converting to Dev Hours

When estimating a backlog, we naturally want to convert that into dev hours as this is what many of us are used to. Do not do it. This brings you back to the same place discussed above where you are removing the complexity, risk, and repeatability from the estimate causing it to be inaccurate. Especially when this is then used to determine the scaling of a team you need to be careful as changing team dynamics will impact the velocity of the team and frequently not in the way you want. 

Compare across teams

Something I have seen leaders start to use velocity as a measurement of value a team is delivering. This is very dangerous and will cause all sorts of bad things to happen in an organization.

1. First, the team will begin to increase their estimates in a way that makes them look better and deliver the same or less value to the organization.
2. Second, this puts a focus on the wrong thing and pushing teams to "go faster" which in turn causes them to produce lower quality products and end up spending more time fixing them.
3. Lastly, this will cause leaders to make bad decisions. Using incorrect data may mean they focus their time coaching the wrong folks or worst-case scenario firing someone who was a valuable member of their organization. 

Packing the sprint full

One of the most common mistakes is to use velocity during the planning session. Though I have done this in the past, recent conversations have made it clear that this causes the wrong attitude during planning. Packing a sprint "full" causes a team to take on too much work at the same time and therefore slows down the "flow" of the work through the sprint. Ideally, we should be closing out work, working out issues with current work, and starting new work once we have capacity to do so throughout a sprint. During planning it is important to come together as a team and consider each next item in the backlog that you think the team can take on and decide to bring it into the sprint. This is referred to as capacity driven sprint planning (6) and is a method that will help the team focus on delivering value rather than cramming the sprint "full"

How to use estimates

Forecasting

The story point or item count method mentioned above can give you a general sense of what your remaining scope is going to take for the same team.

Escape Velocity - Doc Norton

Once we have a velocity established as a team (3+ sprints of completed historical data) we should use that for forecasting what we think we can get done in the future. A couple years ago during Agile and Beyond in Detroit, Doc Norton spoke of a new way to properly use velocity and shared about his book "Escape Velocity" (7). This has been an extremely helpful resource in my experience and helps to have the conversation with the business with % chance of making certain dates showing that this is truly an estimate, and no one is certain of the future.

Closing

In the end estimation is a tool that can be used for good or bad and is meant to help the team keep a sustainable pace for delivering value through working software to their customers.

I hope you have enjoyed this discussion around estimation. As always, I am happy to discuss my experiences in more detail and would love to hear about your experiences. Please, leave a comment below or send me a direct message.

About the Author

Jeff Mortimer (#theAgileMoose) is an Agile Enthusiast with over 10+ years of experience working in various roles on agile teams including business analysis, product owner, scrum master, team leader, and now a technical delivery manager. In additional to his certifications in CBAP, AAC, and A-CSPO, Jeff has presented at several conferences throughout North America and joined the blogger universe a couple years ago to bring a voice to the everyday agile practitioner. He is currently working on an EMBA with Quantics School of Business and Technology. He is a husband to an amazing and intelligent wife who has her doctorate in math education, father to kids who bring him joy every day, friend that brews beer and plays soccer, and citizen who helps organize volunteers to give back to the community.

Follow #theAgileMoose for the latest insights into the agile wilderness.

References:

(1) The logic of noestimates: https://medium.com/serious-scrum/the-logic-of-noestimates-4238e0be3bb6

(2) 12 agile principles: https://medium.com/being-agile/12-agile-principles-in-12-sprints-deep-dive-into-agile-manifesto-163b5131fe9

(3) 12 agile principles: https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/

(4) Why are humans so bad at estimating: https://medium.com/superokay/why-are-humans-so-bad-at-estimating-4b4290f83716

(5) Story Point Picture: https://guide.quickscrum.com/scrum-guide/estimate-story/

(6) Capacity-Driven Planning: https://www.mountaingoatsoftware.com/blog/capacity-driven-sprint-planning

(7) "Escape Velocity" by Doc Norton: https://docondev.com/escape-velocity