Estimating software projects is hard, if not impossible. This seems likely to be fundamental to the work, because we're inventing new things and invention doesn't happen on a fixed schedule. And yet, many teams still estimate how long their tasks will take to finish. Why should you do this, if you can't do it accurately? You do it because it can help you reach your real goal of solving a problem as quickly as possible. But when you do it, you need to have really solid processes around estimating, or the estimates will be used and abused and can kill your team.

Let's establish a baseline first: what's an estimate? It's a measure of how long a piece of code is expected to take to complete. This includes the time you need to do non-code tasks, like reproduce a bug or model your data. This includes the time it takes to test your feature, to write automated tests, and to go through the code review and QA process, since those can lead to code changes. Simply put: it's the total amount of time that you expect any member of your team to invest in this change, in any way.

You can do these estimates a few different ways, such as with story points, t-shirt sizing, or time buckets. One important thing to do, regardless of which metric you use, is to think about and quantify your uncertainty: if you're highly uncertain of an issue's size, then you might want to timebox some investigation into the issue to reduce the uncertainty and de-risk it. These estimates, of any type, are useful to let you know when things are going off the rails¹. Each sprint, you decide on what your team is trying to accomplish. During the sprint, you let everyone know what you're working on and what you're blocked by at a daily standup. That standup is generally the place for you to say "Hey, I'm working on feature X, but it's turning out to be a lot more complex than we thought; could anyone see if I'm missing something, or should we reduce scope on this?" Then your team can make an informed decision and you can either change course to reduce scope, remove some blockers, or charge ahead as planned and accept that this task is more complex than you anticipated (it happens!). But without these estimates, you're flying blind, and you'll just always charge ahead, missing opportunities to reduce scope or collaborate more with your team members.

With estimates, you also are forced to think through things at the beginning. You switch from fast, instinctive thinking into slow, deliberate thinking so you find the true complexity of issues rather than assuming their surface level simplicity is accurate. This is incredibly helpful in reaching where you want to go, because it leads you to focus on creating the shortest path to a solution which you can test with users. If creating a login page is super complicated, well, do you need the login page to test your app with real humans? Or can you hack it, using an identity-as-a-service provider or even using no login for hands-on user trials?

Doing estimates does have drawbacks, however. You need to have buy-in from everyone your team interfaces with, as well, or you risk Deadline Driven Development. If you have solid estimates and the business team gets their hands on them - without explanations from you - you can expect that these features will be promised on some form of timeline. So, you must explain to your stakeholders beforehand that these estimates are only for course correction during the development process, and they're separate from estimates you will give of when features will be done overall. If this isn't done, you can lose trust on your team, you will lose trust of the people outside of your team, and morale can drop precipitously.

The other main drawback is simply that providing estimates takes time, which is time you could spend just writing code instead. If you never use the estimates to adjust what you are working on, then putting in the time to do estimates is a pure waste. However, if you do put in the time to do estimates, you will spend less time coding - but because your team will be able to respond to things immediately, you will still reach your objective more quickly.

An ideal scenario for estimating and using them well looks like this:

• You are using two-week sprints, within the context of a larger goal (solve problem X)
• You have daily standups which everyone on your team attends
• At the beginning of each sprint, you plan what everyone is working on and estimate it to ensure that it's an appropriate amount of work for one sprint (you may also add "background tasks" to fill time when people are blocked)
• Every day, you run standups to see what's at risk of going off the rails and what's blocking progress so the team can get out in front of it
• Whenever things look like they might go off the rails, you reassess and adjust course: shrink scope, expand estimate, or remove blockers
• Throughout the process, everyone outside of the team either cannot see your estimates or understands that they are not deadlines or promises

So go forth and try doing estimates, and see how it goes! It's challenging, but you can improve at it quickly, and the benefits are really great for doing them, especially in a team environment. You will quickly find that you can anticipate issues more quickly and that you think about risks earlier in the project. Just don't let your business team make promises based on them!