Understanding developer estimates

Estimating software work is notoriously difficult. Here's why:

The estimation iceberg

Software work has hidden complexity:

• Known knowns: "I need to add a button." (Clear, estimated accurately)
• Known unknowns: "I need to integrate with an APIWhat is api?A set of rules that lets one program talk to another, usually over the internet, by sending requests and getting responses. Ask AI for more I've never used." (Estimated with buffer)
• Unknown unknowns: "The database schemaWhat is schema?A formal definition of the structure your data must follow - which fields exist, what types they have, and which are required. Ask AI for more doesn't support this, and we need to migrate data." (Impossible to predict)

The unknown unknowns are why estimates balloon. A "simple" change touches five files you didn't know existed.

Why estimates are usually optimistic

Developers estimate the "happy path", everything goes right the first time. In reality:

• The first solution often doesn't work
• Tests reveal edge cases nobody considered
• Requirements change mid-streamWhat is stream?A way to process data in small chunks as it arrives instead of loading everything into memory at once, keeping memory usage low for large files. Ask AI for more
• Interruptions happen (meetings, bug fixes, production issues)

How to work with estimates

• Ask for ranges: "Is this 1-2 days or 1-2 weeks?" A range is more honest than a single number.
• Separate estimates from commitments: An estimate is a guess. A commitment is a promiseWhat is promise?An object that represents a value you don't have yet but will get in the future, letting your code keep running while it waits. Ask AI for more. Don't pressure developers to turn guesses into promises.
• Break down large work: "Build a checkout flow" is impossible to estimate. "Create the cart page," "Add payment form," "Send confirmation email", those are estimable.

Technical debtWhat is technical debt?Shortcuts or compromises in code that save time now but create extra work later when you need to change or extend it. Ask AI for more: The cost of shortcuts

Technical debt is the accumulated cost of quick solutions instead of better approaches. Like financial debt, it accrues "interest", slowing down future work.

What creates technical debt

• Deadline pressure: "Just ship it, we'll fix it later" (later rarely comes)
• Changing requirements: Built on assumptions that no longer hold
• Outdated dependencies: Libraries need updates; ignoring them creates security risks
• Knowledge gaps: A developer did it the only way they knew

Why technical debt matters to you

That "quick fix" from three months ago means the new feature you want now takes twice as long. Every shortcut compounds.

Sprint ceremonies: The rhythm of development

Agile teams work in sprints (typically 1-2 weeks). Key ceremonies keep everyone aligned:

Daily standup

A 15-minute daily meeting where each developer answers: What did I do yesterday? What am I doing today? Any blockers? It's for team sync, not status reporting to management.

Sprint planning

At the sprint's start, the team decides what work they'll commitWhat is commit?A permanent snapshot of your staged changes saved in Git's history, identified by a unique hash and accompanied by a message describing what changed. Ask AI for more to. They break stories into tasks and estimate them.

Sprint demo/review

At the sprint's end, the team demonstrates completed work to stakeholders, your chance to see what's built and provide feedback.

Retrospective

The team reflects: What went well? What could improve? What will we change? This drives continuous improvement.

How product and dev collaborate

Good product/developer relationships are partnerships, not handoffs.

Shared understanding over detailed specs

Don't write a 20-page spec and throw it over the wall. Start with the problem, not the solution. Collaborate on the approach. Accept you'll adjust as you build.

Prioritize together

Developers understand technical constraints. Product managers understand user needs. Best prioritization combines both perspectives.

Questions to ask:

• "What's the technical complexity of each option?"
• "If we do X first, does it make Y easier or harder later?"
• "Is there a simpler way to solve 80% of the problem?"

Respect the maker's schedule

Developers need uninterrupted time for complex problems. "Just a quick question" can derail 30 minutes of focused work. Batch questions and protect the team from unnecessary meetings.

Reading GitHub/GitLab activity

Commits and pull requests

• Lots of commits: Active development happening
• Large pull requests: Complex changes needing careful review
• Stale pull requests: Work sitting without review (potential blockers)
• Merged PRs: Features or fixes now in the codebase

Health signals

Green flags:

• Regular commits, PRs reviewed and merged promptly
• Issues moving from "To Do" to "In Progress" to "Done"

Yellow flags:

• Large PRs sitting open for days, issues stuck in "In Progress"
• Frequent merge conflicts (coordination issues)

Red flags:

• No commits for days (blockers or shifted priorities)
• PRs merged without review (quality risk)
• Constant urgent bug fixes (rushing without proper testing)