Last modified on Fri 21 Jul 2023

This chapter provides some general guidelines that can be used when estimating any scope of work.

Aspects to compare

When comparing future work to past experience, if you neglect some aspect that is roughly the same in both cases, no harm done. But if you neglect some aspect that differs in a way that affects the pace of accomplishment, it can have a major impact on the accuracy of your estimate. Let's look at what aspects might differ.

Aspects of the system

Look at the actual requirements:

Aspect of the development context

The details of the development process have a huge impact on development speed. Rushing into development without proper preparation is a major cause of systems development taking much longer than anticipated. Setting things up for success is the prudent plan.

Effort also depends on duration. It takes effort to get back up to speed after an interruption or delay. Consider work on other projects and the rate at which you can do the work on the main one:

Progress checks

During a project lifecycle, the PMs will require some way to verify that the rate of progress is sufficient. They need to know how things are going so they can make plans and decisions at a macro level.

Give them the honest information they need. If they need more detail, or the data worries them, then you can share a more detailed perspective with them. Most of the time, that more detailed data requires some tacit knowledge of the project to understand it. They probably don't have the time to stay up-to-date on the tacit knowledge of the project, hence the recommendation to give them a useful summary.

If they need a more detailed understanding, it will probably be best to go over your progress indicators with them, helping them understand the context within the project as they help you understand the context surrounding it. Don't just give them numbers - tell them the story.

Don't rely on a percentage of completion as a measurement. Those are very dangerous. When you say it's 50% complete, people will expect the next 50% to take the same amount of time. That's often a bad assumption. Measure slices of usable functionality as units of progress, confirmed by automated tests that check examples of the desired behaviour. A unit of progress can be anything here, how close we are to completing a feature, milestone, or production release deadline. It is usually defined by the tech lead, PM, PO, client. As a developer, ask yourself:

When the conversation resolves around speed and efficiency, you might feel an implicit pressure to go faster, intended or not. If you are trying to improve your performance, never focus solely on speed. Pushing harder often means arriving later at the destination. The more schedule pressure, the less time you can take to look around at factors other than speed. Waste creeps in as:

If you notice that your work is being slower than usual on a project, look for bottlenecks in the code and process:

Diverging estimations and actuals

It's just a matter of time when you'll have a streak of "bad" estimations, where the cause originates from various factors. It's important to look at the silver-lining in these cases: