The planning room usually becomes quiet at the same moment. A story card is on the screen, someone asks how big it is, and the team starts looking for a number that will not create trouble later. A developer thinks it is small. A tester remembers three edge cases. The Product Owner hopes it fits this sprint. The number is supposed to be simple, but everyone knows it carries more than size.
That tension is why Agile Estimating and Planning still feels useful. Mike Cohn is not trying to make software predictable in a mechanical way. He is trying to make planning more honest. The book keeps reminding us that estimates are not promises carved into the table. They are structured conversations about size, risk, knowledge, and trade-offs.
This article is a personal reflection from Agile Estimating and Planning by Mike Cohn, published by Prentice Hall / Addison-Wesley Professional in 2005. I am not summarizing the whole book. I am pulling out the ideas that still help teams discuss estimates, velocity, and planning without turning those numbers into pressure theater.
Planning matters more than the plan
One of the cleanest ideas in the book is that planning is an activity, not a document. A plan is only a snapshot of what the team believed at one moment. Planning is the habit of updating that belief as the team learns. This sounds simple, but it changes the emotional load of estimation.
In many teams, the first estimate becomes a quiet contract. A feature is guessed at eight days in January, and by March everyone behaves as if that number came from physics. Agile planning asks for something calmer: keep the estimate visible, keep the assumptions visible, and replan when reality has taught the team something new.
Imagine a team integrating with an old customer identity system. Before touching the code, the team may think the story is small: call one API, map a few fields, done. After a spike, they learn that the API behaves differently by tenant, error messages are inconsistent, and test data is hard to create. The work did not become larger because the team was careless. It became clearer because the team learned.
A useful replan can stay very small. The team may keep the original story, but split out one spike to document tenant behavior, one read-only sync slice, and one write-back slice with error handling. The conversation changes from “why did the estimate grow?” to “which assumption changed, and which slice gives us the next useful learning?”
Separate size from duration
Cohn’s separation between size and duration is one of the most useful habits in the book. Story points estimate size: effort, complexity, and risk together. Duration comes later, through the team’s actual velocity. This prevents a common planning mistake: pretending that every person, every week, and every interruption-free day is the same.
A login story and a profile update story may both sound small. But if login touches security, audit logs, password reset, rate limiting, and multi-device behavior, its size is different. Story points let the team compare work relatively before pretending to know the calendar. The question becomes, “Is this like that previous story, or is it two or three times heavier?”
| Planning shortcut | What it hides | A better conversation |
|---|---|---|
| “This is two days.” | Assumes no interruption, no discovery, and one person’s context. | “This is similar to the previous 3-point story, but testing risk is higher.” |
| “Our velocity must be 40.” | Treats velocity as a target instead of measured evidence. | “Our last three iterations were 28, 31, and 30. Let us plan around that range.” |
| “Just split it into UI, API, DB.” | Creates technical tasks instead of user-visible slices. | “What is the smallest vertical slice a user or PO can accept?” |
| “One ideal day equals one calendar day.” | Ignores meetings, support, review, incidents, and context switching. | “How much uninterrupted effort is this, and how much real capacity do we have?” |
The self-correcting part is important. If a team estimates all stories a little too small, velocity will also be lower than expected. The plan corrects through observed velocity. That is healthier than forcing the team to keep defending every original guess.
Planning poker works because assumptions become visible
Planning poker is not valuable because cards are fun. It is valuable because hidden assumptions become public. When everyone reveals a number at the same time, the difference between the highest and lowest estimate tells the team where to talk.
Suppose a story says, “As a user, I can export my transaction history.” One engineer chooses 3 because they imagine a CSV download from an existing query. Another chooses 13 because they know the export must include permission checks, large files, time zone handling, masked personal data, and audit events. The number is less important than the conversation that follows. The gap tells the team what nobody had said yet.
This is also why planning poker should not drift into deep design. A few minutes of clarification are useful. A long architecture meeting during estimation usually means the story is too vague, too large, or carrying too much risk. In that case, a spike or a smaller story is often better than one heroic estimate.
Ideal days are helpful until they are mistaken for calendar days
The book gives ideal days a fair treatment. They can be useful because stakeholders understand days more easily than abstract points. But ideal days become dangerous when someone quietly translates one ideal day into one day on the calendar.
A real workday is not a sealed room. It contains code review, support questions, short meetings, deployment checks, production noise, helping teammates, and small interruptions that never appear in the estimate. A task that needs two ideal days of focused work may not finish in two calendar days. That does not mean the engineer was slow. It means the calendar contains more than the task.
A practical example is a QA-heavy story. The coding may be one ideal day, but the team also needs test data, acceptance examples, regression checks, and maybe coordination with support. If those are not counted, the plan looks efficient on paper and stressful in real life.
Velocity is team data, not a scoreboard
Velocity is useful when it is treated as evidence. It becomes harmful when it is treated as a KPI. A team’s velocity belongs to that team, with its codebase, domain, people, interruptions, tooling, and definition of done. Comparing two teams by velocity is like comparing two kitchens by how many plates they carry without asking what they are cooking.
The all-or-nothing rule helps here. A story contributes to velocity only when it is done, tested, and accepted. That can feel strict, but it protects the meaning of done. A story that is 90% coded and 0% accepted is not 90% usable for the customer. The team may be close, but the product has not received the value yet.
Individual velocity is the opposite direction. Once people are measured by personal points, collaboration becomes risky. Helping a teammate, reviewing carefully, pairing on a hard bug, or supporting QA may reduce one person’s visible output while improving the team’s actual delivery. A planning metric that punishes teamwork is measuring the wrong thing.
Instead of saying, “We commit to finishing all 50 points,” try: “Based on the last three iterations, we are planning around 28 to 32 points. These two stories are risky, so if they grow, this lower-priority story is the first candidate to move out.”
How I would bring this into a team
I would start small. First, choose a few reference stories that the team understands well: a tiny bug fix, a normal CRUD change, a cross-service integration, and one risky story that required discovery. Give them shared point values. These become the team’s measuring stones.
Second, keep estimates attached to assumptions. If a story depends on a vendor sandbox, unclear permission rules, or data migration, write that down beside the estimate. When the assumption changes, the plan changes without needing drama.
Third, use velocity as a range after a few iterations. One iteration is still noisy. Two or three are better. Four or more start to show a useful pattern. The goal is not to make the team faster by demanding a larger number. The goal is to make the release conversation less dependent on memory and pressure.
Key takeaways
- Planning is continuous. The plan is a snapshot; planning is how the team updates its understanding.
- Story points estimate size, not calendar time. Duration comes from observed velocity.
- Planning poker exposes assumptions. The gap between estimates is where learning happens.
- Ideal days need care. They describe focused effort, not real calendar days full of interruptions.
- Velocity is team evidence. It should guide planning, not become a scoreboard or a management target.
The quiet value of Agile Estimating and Planning is that it gives teams a more honest language. Not a language that removes uncertainty, but one that helps people talk about uncertainty without hiding it. A good estimate does not make the future obedient. It helps the team see what it knows, what it assumes, what it still needs to learn, and what decision is reasonable for now.