Release Dates vs Logic: FIGHT!

Why deadlines are meaningless without science

We've all been there: You've been handed a chunk of work and a deadline. The work is extremely over-ambitious (/impossible) given the timeframe and your team's resources​, but it's already been decided, and there's nothing you can do to change it. And if your team doesn't meet that deadline, it's a black-mark against you and your engineers. Time to panic. But is it, though? Deadlines and timing are one of the greatest sources of stress in today's engineering cycle of constant release. But many of the deadlines engineers receive aren't based on any kind of logic or backed by any information at all. Today I'm going to tell you why those kinds of schedules are meaningless, and how to fight against them.

​Mandates based on Nothing

​A directive that is attached to a specific timeline is meaningless if it's not informed. ​What does "informed" mean? It means that work takes time. If you, or a member of your team, weren't consulted on how long a particular chunk of work is going to take, a deadline can't be logically determined. Any timeline that's delivered to you without consultation, determined by a person who doesn't have any experience doing the kind of work that's desired, can't be taken seriously. If timelines aren't based on historical data or advised by the engineers doing the work, then most times, it's doomed to fail. So what data do we need to construct meaningful schedules?

History

​The type of information we need is historical data on how the team has performed in the past. Concrete information on past performance is arguably the best way to determine the team's rate of work, and estimate timelines for new work. But since no two lines of development are exactly the same,  how can timelines for new work be accurately estimated from history, if there are no direct correlations between historical work and planned work?

​Estimation

​The answer is for engineering teams to estimate the complexity of tasks before they occur, and then compare those estimates to actual outcomes. Once a few releases have been tracked this way, a correlation can be drawn between the estimated complexity of work, and the time that work takes to complete. One tried and true way to achieve this is to use ​story points. Without getting into too much detail, a story point is a rough estimate of the complexity of a task, which divorces the estimate from actual units of time. By estimating scope of work without actually assigning units of time to tasks, we can then determine a team's velocity, or roughly the amount of complexity that can be tackled in a given timeframe. Using all that data, we can take a planned set of tasks, and estimate how long they'll take. Compiling this type of data is key not only for creating schedules, but also in tracking the team's success. If a team's established velocity suddenly drops during a particular release, that can be an indicator that something is wrong or is draining the team's efficiency.​ Estimation of work is absolutely crucial in developing realistic expectations and measuring success.

To sum up, a deadline needs to be informed by consulting experts on the work being done. Development work takes as long as it takes, and consistently forcing unrealistic timelines on an engineering team is a good way to burn out the engineers and crush morale. To hold a team responsible for a deadline they were never consulted about, or that doesn't consider any historical information about that team's velocity is simply ​unreasonable. But if you consider facts, consult engineers and perform due diligence when constructing product roadmaps, you set your teams and people up for success and give them the input everyone needs for deadlines to be justified.​