liveBook · Manning

Estimate

As explained in Lead Developer Career Guide

An estimate expressed as the number of hours expected to complete a task or project.

An hourly estimate is the number of hours expected to complete a task or project. It helps a project team plan its timeline, resources, and budget. Unlike story points, which express relative effort, an hourly estimate expresses expected time. It can be useful when deadlines and budgets are tight or when a consultancy needs to bill a client for its work. section 7.2 section 7.2.1

A lead developer helps prepare project estimates, but the developers doing the work should help shape them. Early estimates follow a proposed technical approach and may change as requirements become clearer. Gather feedback from stakeholders and the team, then refine the estimate rather than treating the first number as final. section 1.2 section 7.2.3

To make an hourly estimate more useful:

  • Clarify the requirements and scope: what work is included, what is excluded, and which dependencies must be met. Check your understanding with developers and the project manager before work begins. section 7.2.1 section 7.2.3
  • Break the project into manageable tasks. Use time spent on similar work as a guide, and account for factors such as the availability of people who must collaborate. section 7.2.1
  • Review the estimate as the work develops, allowing for unexpected roadblocks. Communicate timing and progress to the project manager regularly so plans can be adjusted. section 7.2.1 section 7.5.3

A scope change that affects the estimate

Suppose a developer adds unrequested features to improve a project. Even if the additions seem helpful, they take time that was not included in the agreed scope. Discuss the proposed change with the project manager before doing the work, then revisit the estimate if the scope changes. section 7.2.3

An estimate that is too low can push a team toward overtime, missed deadlines, and burnout; one that is too high can delay delivery and use more resources than necessary. The goal is a realistic planning figure, supported by team input and updated when circumstances change—not an unchangeable promise. section 7.2 section 1.2

How Lead Developer Career Guide covers it

How deep it goes
Defines hourly estimates, contrasts them with story points, and gives a practical sequence for scoping, breaking down, checking, and revising work.
Examples
Uses fixed-budget projects, consultancy billing, team availability, and an out-of-scope feature addition to illustrate estimation decisions.
What it assumes
Assumes familiarity with software project teams while defining hourly estimates and story points without requiring a particular estimation method beforehand.
What you can do after
Practice/perform hourly estimation by clarifying scope with the team, breaking work into tasks, considering prior work and availability, and revising estimates.
How it connects
Links estimates to project scope, story points, technical debt, project budgeting, and stakeholder communication.

Also explained in

Compare how 2 books explain estimate →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Lead Developer Career Guide. The section links point to the parts of the book it draws on.