For a good estimate you need to start with one very important thing: define if you estimate based on time to complete or  time to deliver. These are very different because the time to deliver will be substantially higher and much more prone to variations. This is because in the daily work you will be dragged into meetings, have people distracting you and so on. For good estimations we always estimate on time to complete as our basis.

Stop doing happy estimates

The worst thing you can do is making happy estimates. These are estimates based on the utopia that everything will work smoothly and you will be left in total isolation to focus. It never happens and Murphy is always present. Happy estimates may seem good because the product owner love low estimates, but they hate when you fail to deliver.

Happy estimates usually happen when an architect is stressed and throw out a guesstimate on the fly. It will almost always bite you in the butt because not only will everything seem easy to the architect, so they will underestimate it, they also never consider Murphy.

You do not estimate to be nice, you estimate to give a realistic view on when something can be available in production. If you have a hard time to stop making happy estimates, then implement this very simple rule:

"Any time that is needed beyond the time you have estimated you will do in your own time without payment"

Take your time doing estimates

An estimate is not a guesstimate that you throw out on a high level requirement. An estimate is your promise on when you can deliver and as such you should take your time and think that through. Don't sit around doing arbitrary guess work in a planning poker or play with t-shirt sizes unless you want to avoid doing any estimates at all. That type of guesstimating is for high level requirements, so make sure they stay there.

Break down the requirement and use your experience to guide you to a first number in your estimation. This estimate is how long it will actually take to sit down and build based on the requirement. Make sure that you ask questions to clarify where needed so have the information you need. This is also a good time to start working on a solution design to make sure you have considered things that may not always be apparent. For example validation of data in integrations or extending a JavaScript validation for a new form.

When we have done this, the number is still wrong, but we need it as a starting point.

Add the things you forgot

Now that you have done your estimate, many think they are done. That is rarely the case, so let us add the things that is not included yet. The most obvious problem that I see a lot is that the estimates is usually done by the most experience person, which also usually is the one that work fastest of everyone in the team. So what we do is to look at the estimate and the team, then we adjust based on what the slowest person in the team think is appropriate. This way we know that the base estimate is reasonable for everyone on the team.

The second thing we do is to consider Murphy. Things always happen and based on the complexity we increase the estimate with 20-100%. Not having room for mistakes is in itself a very big mistake. It will almost always happen and if it does not happen for this particular task we will either be able to resolve things faster than expected, or we have more time for other tasks. Either way that is a positive thing.

The third thing to look at are testing. All code should have unit tests and it is often forgotten in the estimate. You also have non-functional requirements such as loading times and browser support that you must consider. As a developer you are also responsible for testing the code and this should be added as a second estimate. For many estimates this alone will add 20-200% or even more to the estimate. This is especially true for frontend development where you often have 18+ variations just for devices and browsers.

These three very simple things easily multiply the original estimate two to three times.

Now let us consider your efficiency!

A factor that is very often overlooked is efficiency. No person in any team will ever have 100% efficiency in the sprint. I do not mean your focus level during the day, even if that also is a factor, I am talking about those pesky things that break your concentration. Things like meetings, stand-ups, code reviews and all those "I just want to ask a quick question", cost a lot of your time during the day. In my experience most teams will have an efficiency of around 40-60% depending on how often they are disturbed.

Depending on if your product owner understand estimation or not you can choose if you add the efficiency in the estimate, or if you have that as an external factor in the sprint itself. If you are new to this part of the estimation I suggest that you start with 50% efficiency and then adjust over time as you get better at estimating your efficiency.

With this step we now add a second two time multiplier and you are now close to a realistic estimate.

This may seem like a lot

This may sound like the estimates always will be very high compared to how you are working today, and you are right. This is why you always feel stressed and why you fail to deliver on promise in every sprint. It is why we invent things like story points to mitigate our inability to take responsibility for things we can't estimate properly. Realistic estimates are just that and if your estimates are far lower than what you get doing estimates this way, then remember this very simple rule:

It is always better to overestimate and over deliver than to underestimate and under deliver.

The Quick Summary

1. Make estimations in actual time to complete, not arbitrary measurements.
2. Take your time to understand the task at hand and stop guesstimating.
3. Adjust the estimate to fit the slowest person on your team.
4. Add task for testing and make estimation separate for that.
5. Remember that things always go wrong, so make room for that.
6. Make sure that your efficiency is considered and calculated into the time to deliver.

Making good estimates is based on experience and knowledge. This means that like other skills you can get better at it. If you constantly work with arbitrary measurements like story points and you constantly fail with no change to your estimation process, then you should stop doing that. Not only will you fail at a crucial part of your work, your inability to provide accurate estimates actually cause harm in the form of stress and frustration. It is up to you if you want to spend your time in constant failure or constantly provide estimates that are realistic and dependable.

Learning to make good estimates is not rocket science, just common sense and experience.

So start doing it today.

The reason we estimate and log time have nothing to do with the development team. We do this to make sure that resource and finance planning have the information they need to get funding and resources. It also to make sure that collaboration and dependencies can be managed.

So when the developers estimate it is to make sure they have the time they need to complete their work. We log time so management can see if problems arise should our estimations not hold.

When you fail to estimate, then you actually compromise your own time since your estimation decide the amount of time you have to do the work. When you fail to log time you not only make life difficult for the teams that depend on your work, you also limit the possibility to adjust expectations and budgets. This again reduce the time you have at your disposal.

Don't.

Unless you exist in an isolated team with no collaboration or dependencies outside your own team, and you have your own budget, then story points will be completely useless. Even though story points are time allocations just like time based estimates, they have several drawbacks that make them less than ideal for estimation purposes.

1. Story points are arbitrary - This means that each team will have their own version of what a story point is. With no common point of reference it becomes impossible to use in situations where you work with accumulated data from multiple sources. Like portfolio management.
2. Story points are unflexible - This means that story points act as fixed size time slots with fixed ratios. That means that most estimates will either be a very snug fit or very loose fit. There is no one size fits all version in time estimations. That is for guestimations.
3. Story points are abstract and hard to understand - Since story points are made up of measurements that is also arbitrary, it is very hard to grasp what they mean for people working with time as focus for resource and finance planning.
4. Story points have no path of learning - This means that if you assign a value and you complete the work in that time slot, then you will never change that, even if the estimation was way too big. There is no proper learning curve as you either overestimate or underestimate and you either fail or succeed. You never learn by how much you over or underestimate as you never log more or less points.
5. Story points can't show progress - Story point can't be counted down like time based estimates. You only log start and completion, nothing in between. This can make for long periods of time before and update, which will make dependency management near impossible. Many reports will also be useless.

One of the most asked question about estimation with story point is how to translate to time. This is because story points does not work in most cases due to the fact that the rest of the world deal with time, not made up increments of arbitrary measurements.

So use always use time based measurements unless management tell you they need the estimates in that arbitrary measurement.