Everything we do has a cost. There are personnel, equipment, and time costs. There is a cost in resources, hardware and software, systems and support to develop our products. There are also opportunity costs of using our resources to develop one product which then prevents us from developing other products we could have built. We can use some Agile principles to help us understand what the cost of developing some of these products and features is before we begin. Accurate estimation helps us be more predictable and meet business and team goals.
Before going any further, let’s have a quick review of the one of the first things you learned in Physics class. Distance equals Velocity multiplied by time. d=vt. If you’ve ever taken a physics class you’ve learned this concept and used it as a building block for many other formulas which are far more advanced. How far we can go, is dependent on how fast we can go and how much time we have. This is a basic concept when you think about it in familiar terms like your last road trip. The faster you drive, the more distance you cover in a given period. The same principles hold true for Agile teams, and we can use our knowledge of two of the variables to solve for and plan the last variable. Most commonly, we want to figure out our Distance and our Velocity, to calculate the Time needed to complete.
Why do we Estimate?
It’s essential to every organization to make the best decisions possible when selecting which products to develop, and that’s why our discussions on developing and grooming our Agile backlogs often revolve around the value that they provide to the business. When making these decisions, it’s important that we have estimated the size and complexity of these items, so we have a good understanding of the resources they will require to develop. The size of a backlog item and its value to the business have ZERO relationship. So when given two equally valuable backlog items, we need to know the small from the large so we can build the small items first and begin delivering value faster.
Additionally, with accurate estimates, we can forecast our production consistently to know when things will be done and can be sold to the consumer. With accurate estimation we can begin to understand what a team can do in a sprint. This becomes a powerful planning tool when trying to understand the resources that will be required to develop a backlog item.
Estimation using relative Size and Complexity
In Agile we don’t usually use time as a reference for estimation of a user story. Time is a bad comparison for lots of reasons. For one, different people will need different amounts of time to do the same work. Also, as humans we don’t track time very well in our heads, and interruptions are common in our workday, which can blow up our perception of the time it takes to do something. The common idiom “time flies when you’re having fun” is an example of how bad humans are at perceiving actual elapsed time. The same amount of time can be perceived to take wildly longer or shorter depending on our mental state. Additionally, a lot of work is highly to discovery, we are not doing something that has been done before, so we can’t know exactly how long it will take.
Most people won’t estimate the same task to take the same amount of time. We all have different skill sets, so this makes sense. A common example we use to further illustrate this concept is running a mile. Regardless of who runs the mile, the same amount of work will be done. If I run the mile, it may take me 10 minutes. Yet a very fit co-worker might be able to do the same job in 6-7 minutes, while another might be closer to 20 minutes. Either way, only a single mile has been completed. The time it takes does not give us an idea of the relative size and complexity of running that mile. In Agile, we compare stories based on relative size and complexity. What if it is a mile up a set of switchbacks on a mountain? We can agree that 2 miles is more than 1 mile. We can also agree that a mile up a hill is more complex than a mile on flat ground.
A common way to combine all the relative size and complexity measurements into a single figure is with T-Shirt sizes. X-Small, Small, Medium, Large, X-Large. There should be enough of a difference between a small t-shirt and a medium t-shirt to be able to clearly tell the difference. We can also use the concept of story points following a Fibonacci scale… 1, 2, 3, 5, 8, 13. We use this scale because a 5 clearly conveys a sense of larger size and complexity than a 3, whereas the difference between a 4 and a 5 might be difficult to discern and agree on. A 1 mile run up a slight incline might be a 3, while a 2 mile up a steep incline may be a 5.
The size reference
One of the most important aspects of proper estimation is to stay consistent over time. Something that can help greatly with this is to have a reference story. A reference story is a Small User Story that everyone on the team is familiar with. Hopefully everyone has done it before or can at least relate and understands the size of complexity of it. This reference story will likely remain constant across multiple sprints. Perhaps over time you might also add a Large and a Medium to continue rounding out the sizing. But if everyone can agree that “X” is a small, and across multiple sprints that is the benchmark, it becomes easier and faster to size other stories relative to that small one. I would start with bookends, like Small and Large, use that for a while and then you can start expanding if necessary.
A few other tips:
Estimates are not commitments. We estimate as a predictive measure, not a commitment. If a team member’s bonus is dependent on the accuracy of their estimate, it will inevitably inflate the estimate. This will reduce the accuracy of our estimates and cause additional stress and contention over them. Team members will be more prone to deliberate back and forth over whether an item is a medium or a large, and more time will be wasted. We won’t get a true picture of the capacity of the team over time, and we are less able to pivot with changing requirements or the discovery of new information that would affect those estimates.
Accuracy vs Precision – Our Agile estimates should aim at being accurate without trying to be too precise. Precision is essential in many areas, but not in this one. Embrace the concept of ‘close enough’ when sizing your backlog and move quickly through stories when refining it, pausing when necessary to discuss stories where there is confusion. Go with your gut on this, a lot of the time it will be the best estimate. We can’t know the future, so it is not efficient to agonize over whether each story is a 2 or a 3. A 5 or an 8. If you move quickly and go with your instincts, you’ll probably over-estimate as much as you under-estimate and it will all work out in the end. If you are stuck between two, pick the higher estimate and move on.
The Takeaway
We need to know the cost before developing something, so we can make proper planning decisions.
Estimate early and continuously refine that estimate as you learn more, all the way up to sprint planning before a story goes into an active sprint. Stay agile and flexible to deal with changing information.
Proper Agile estimation is how we determine the Distance part of our d=vt equation. How far do we have to go? How much work do we need to complete? How much time will it take?
Focus on accuracy over precision.
Use a Fibonacci sequence of numbers to assign story points that convey the relative size and complexity of user stories.
See the companion blog on Velocity to see how estimation is used to forecast and track team progress!