Agilists, it’s 2020, Stop Estimating and Start Projecting

Ever since the debut of the waterfall project management technique and the famed software development lifecycle, people have been hooked on estimating software development activities. Many of my fellow agilists and product managers still find comfort in the estimation of individual tasks in this line of work.

When we start going down this path of estimation, we start to hear questions like…

As an Agile Delivery Lead, it’s not uncommon to see product managers asking for dates and estimates, often disguised as the questions above. Sure, they need to know when something will be done, and the conversations that ensue are often important, but there are better ways of answering these questions!

Out With the Old

First and foremost, it’s easy for Agilists to respond to these questions with something along the lines of “Well, if I just look at my team’s velocity I can see that…”

You could, but you shouldn’t.

This is what I like to call a slippery slope. It starts with just one team, then it spreads, resulting in teams being compared against each other, and morale going down the tubes.

For those of you not familiar with velocity, it’s a common metric that represents the total number of “points” a team delivered based on how they estimated their work in terms of complexity, unknowns, and effort. The teams then use a fibonacci sequence (or some other sizing methodology) to assign that item a “point value” after reaching consensus as a team. The conversations that result are always valuable, but the outcome is not always worth the investment (i.e. opportunity cost).

Unfortunately, a point for one team is not the same as a point for another, and this is where things get tricky… Team velocities cannot be compared, and there is really no such thing as a “normalized” point value. However, teams are often held to these estimates and point values, causing 40 hour work weeks to potentially become 50, 60, or more hours long.

This may be an exaggeration of course, but at the end of the day, there are better ways of determining when something may be done!

Projections > Estimations

So when it comes to answering the aforementioned questions, surely you cannot count on past performance as a guarantee for what the future will hold, but you can use it to project. The past performance of a team can be an indicator of future outcomes provided that certain things remain constant such as throughput, amount of work in progress (WIP), and cycle time. From there, you can then effectively project when new work might be completed with more certainty than before. Definitely more certain than your points would be.

This gives you the opportunity to leverage Little’s Law, which states that the average throughput of a system equals the ratio of the total average WIP over the average cycle time (Little, 1961). You can also flip this to calculate cycle time, instead.

Time and time again, teams are always pushed to increase their velocities, or number of points delivered, so what’s to say that these teams aren’t being disingenuous about their point values? Nothing. That’s not to say cycle time cannot be manipulated, but then given what Little’s Law states, you will see a difference in your WIP or throughput as a result.

We already know that a point is different for every team (and person) and as such, we should simply count the number of work items completed. The result then, is that we start looking at raw data to drive discussions and put a finger on “When will it be done?” rather than guessing.

Objections?

Given what you just read, you may think “Not every work item is the same size!” and of course you’d be right. Story slicing, as it’s often referred to, can be an entirely separate discussion, but in short, you should strive to have similarly sized items. Even if they’re not though, the law of averages takes over. We’re not looking to be 100% accurate, we really just want to project with some level of certainty.

Furthermore, you might be thinking that you don’t have the necessary data to get you on your way. Perhaps you have a new team, or one that, quite frankly, is less experienced. Regardless though, my answer would be the same: just get started.

Pick whatever is the highest priority item on your backlog and work through it. Then at the end, look back in retrospect and ask your team, or yourself, questions such as:

• What negatively contributed to the cycle or lead time of this item?

• Was this story too big or, could we have delivered a smaller piece of value sooner?
• How do we improve for the next time?

Once you embark on this journey, you’ll see that these projections can come in many different forms. It could be as simple as handwritten math or plotting numbers on graph paper, or it could be via a tool like JIRA®, Kanbanize®, or ActionableAgile™, to name a few.Above: Screenshots from ActionableAgile

At this point, just by looking at cycle time and throughput alone, we can then say “If the WIP limit is 5, and each item takes an average of 5 days, then every 6th item in the backlog is 10 more days away from being completed.” Having data to back your work up is much better than taking a guess on a point value, right?

While it might feel uncomfortable at first, you must hand the clock to the developers.

Whether they’re working with an Agile Delivery Lead or on their own, if they know how long a work item takes to complete they can work to drive that number down. The same can be said for work in progress; if it’s high, it’ll negatively impact cycle time so help them lower it. Every good system needs slack, so don’t spread yourself, or your teams, too thin.

Estimates are always guesses and they’re always wrong. You really don’t want to be betting your company on guesswork.

Allen Holub

At the end of the day, Agile Delivery Leads should be striving to save our developers time. We shouldn’t be needlessly asking them to estimate work, as those estimates are usually wrong. Just use the data you already have and visualize it. Start having conversations, and really ask yourself (and your team): what would our world look like without estimation?