Book Notes #14: Agile Estimating and Planning by Mike Cohn

Title: Agile Estimating and Planning
Author: Mike Cohn
Year: 2005
Pages: 368

Agile Estimating and Planning is the definitive, practical guide to estimating and planning agile projects. 

In this book, Agile Alliance cofounder Mike Cohn discusses the philosophy of agile estimating and planning and shows you exactly how to get the job done, with real-world examples and case studies.

As a result, I gave this book a rating of 8.0/10.

For me, a book with a note 10 is one I consider reading again every year. Among the books I rank with 10, for example, are How to Win Friends and Influence People and Factfulness.

3 Reasons to Read Agile Estimating and Planning

Book Overview

Let’s be honest—when most people hear “planning,” they imagine endless spreadsheets, bloated Gantt charts, and deadlines that are more fantasy than forecast.

But what if there were a different way to plan? One that embraced uncertainty instead of pretending it didn’t exist, that relied on teamwork rather than top-down mandates, and that actually got better the more you used it?

That’s the question Mike Cohn answers in Agile Estimating and Planning.

From the very start, Cohn sets out to redefine what it means to plan.

Instead of building detailed blueprints based on made-up precision, Agile planning is about creating direction through frequent, flexible collaboration.

It doesn’t promise certainty—it promises alignment. And the way you get there is surprisingly human.

Take the humble user story, for example. Instead of documenting every requirement upfront, Agile teams write short stories that describe a user’s goal, what they need, and why it matters.

It’s a way to center real people in the planning process. And rather than trying to predict exactly how long something will take, teams estimate how big the work is—using story points as a shared language of effort, complexity, and uncertainty.

The Magic Isn’t in the Charts. It’s in the Conversations.

Agile offers plenty of charts—burndown, parking lot, even bar-style release tracking.

But none of them matter if the team isn’t communicating. In fact, one of the most powerful takeaways from the book is that planning in Agile is never about the artifacts.

It’s about the ongoing conversation between the team, the product owner, and stakeholders.

Charts just make that conversation clearer.

Whether it’s a release plan based on real user value, an iteration plan built from collaborative task breakdowns, or a prioritization session using models like Kano or relative weighting, everything in Agile planning points to one core belief: if you can talk about it, you can improve it.

And if you revisit that plan often enough, you’ll rarely be caught off guard.

In the final chapters, Cohn brings everything full circle. He explains that Agile planning works not because it’s perfect, but because it reflects how work really happens.

Plans change. People learn. Priorities shift.

Agile teams don’t try to freeze those things—they learn to move with them. Frequent replanning, clear definitions of done, cross-functional collaboration, and the ability to break big things into small pieces are what allow Agile teams to stay focused without getting stuck.

And perhaps most importantly, Agile planning brings trust back into the conversation.

When teams estimate together, plan together, and deliver together, they create transparency.

And when stakeholders see that transparency, they stop asking for impossible promises and start collaborating on better outcomes.

By the time you close the book, you’ll see that Agile Estimating and Planning isn’t really about numbers, charts, or techniques. It’s about mindset.

It’s about choosing clarity over certainty, conversations over control, and learning over guessing.

Cohn doesn’t offer a magic formula—but he gives you something more valuable: a practical, proven way to plan work that respects both the complexity of software and the people building it.

So, if you’ve ever felt that planning was broken—or worse, pointless—this book might just restore your faith. Not with big promises, but with small, deliberate practices that help teams move forward with confidence.

Not because they have all the answers, but because they know how to find them—together, one story at a time.

But in the end, how to estimate?

Estimation in Agile isn’t about being perfect—it’s about being helpful. In Agile Estimating and Planning, Mike Cohn shares simple techniques to help teams make better decisions, set clear expectations, and work with more confidence. Each technique serves a different purpose, depending on where you are in your planning process. Here’s how they work and when to use them.

Story Points are one of the most important concepts in the book. Instead of estimating time, teams estimate how big or complex something feels. Story points capture effort, complexity, and uncertainty all in one. It’s like saying, “This task feels about twice as hard as that one.” They’re great for planning releases or sizing up the backlog quickly without getting stuck on hours.

Ideal Days are a time-based alternative. You ask: “If I worked on this without distractions, how many days would it take?” This is easier to understand for people new to Agile, but can lead to confusion if taken too literally. It’s better used as a starting point for teams transitioning from traditional planning.

When it’s time to get into the details of a sprint, teams can switch to Ideal Hours. These are used to estimate small tasks after a story is broken down. Ideal hours help teams check how much they can really fit in an iteration. It’s not about tracking time—it’s about balance and visibility.

To get everyone involved in estimating, Planning Poker is a fun and effective tool. Each team member votes on the size of a story, and then the group discusses any differences. It leads to better conversations, shared understanding, and fewer hidden assumptions.

If you’re planning a release, you’ll need to estimate how fast the team can go. That’s where Forecasting Velocity comes in. It’s about looking at how many points the team finishes each sprint and using that average to plan the future.

When you don’t have past data, you can try Running a Trial Iteration—just do a sprint and see what you complete. Real data always beats guessing.

Sometimes, planning needs to include a safety net. That’s where Buffering helps. If you expect surprises, you can add extra time (a schedule buffer) or include extra, lower-priority features that can be skipped if needed (a feature buffer). It’s not padding—it’s being honest about uncertainty.

Finally, for very early planning or high-level discussions, T-Shirt Sizing can be helpful. You don’t use numbers at all—just call stories Small, Medium, Large, or XL. It’s quick and works well when you don’t need precision yet.

In short, Cohn’s techniques give you options.

Use story points for big-picture planning, ideal hours for sprint-level work, and velocity to guide your roadmap.

If you’re starting fresh, try a trial sprint or simple sizing.

If you’re under pressure, add a buffer.

The goal isn’t to find the perfect number—it’s to create better conversations and more reliable plans, without getting stuck in the weeds.

Story Points?

Imagine you’re packing for a trip. You have three bags in front of you:

• A small backpack
• A medium-sized suitcase
• A huge travel bag

You’re not measuring the weight in kilos or how many hours it’ll take to pack each.

You’re just thinking: “This one will be easy, that one will take a bit more effort, and that big one?

Oh boy, that’s going to take a lot of time and energy.”

That’s exactly what story points are.

Instead of guessing how many hours a task will take, you and your team ask: How big, how complex, and how uncertain does this feel compared to other tasks?

Let’s say you’re building a simple login page.

You’ve done it before, it’s straightforward—so you call it a 2-point story.

Now you have to build a password reset feature. It’s a bit trickier, has some edge cases, and touches more systems. You think, “Hmm, this feels about twice as much effort as the login page,” so you call it a 4-point story.

Then someone brings up building a whole new user profile management system, with settings, preferences, and integrations. Everyone agrees: “That’s way more complex—maybe 8 points.”

You’re not saying 2 points equals 2 hours, or 8 points equals 8 days. You’re just comparing them—kind of like saying:

“If the login is a muffin, the profile system is a layered birthday cake.”

And over time, your team learns how many “points” you can typically complete in a sprint.

That’s called velocity. So if you usually complete 20 points every two weeks, you can start planning how much work to take on, without needing to guess exact hours every time.

So in short: Story points = relative size.

They help you estimate effort, complexity, and uncertainty—not time. And they keep planning simple, fast, and team-friendly.

Why Story Points Aren’t Just About Effort

A big important point in the book is what story points actually measure.

It’s not just time. It’s a combination of effort, complexity, and uncertainty.

That mix is what makes them so powerful—and also what trips people up when they try to translate them into hours.

Cohn argues that the real value of story points is in the relative comparison: this story feels about twice as hard as that one.

Once teams start thinking in these terms, estimation becomes faster, more consistent, and more useful for planning real-world releases.

Cohn walks through how velocity (the average number of story points a team finishes per iteration) becomes a heartbeat for planning.

Instead of guessing delivery dates out of thin air, you can forecast with a real rhythm—one that improves with time and experience.

But he’s careful to remind us: velocity is not a performance metric.

It’s a planning tool.

Using it to compare teams or individuals is like judging marathon runners by their shoe size.

Why Comparing Velocity Between Teams Is a Bad Idea

Velocity is a tool for one team to track its own progress over time—not a score to be compared across different teams.

That’s because velocity is based on relative estimates unique to each team.

One team’s five-point story might involve building a complex API, while another team’s five-point story could be a simple UI update.

If you try to compare the two, you’re comparing apples to oranges.

Their story points are based on different standards, different skills, and different work contexts.

When leadership starts comparing velocity across teams, it unintentionally introduces pressure to inflate estimates or “game the system.”

Teams may start assigning higher point values to the same work just to appear more productive.

This destroys the accuracy of the planning process and undermines trust.

Worse, it can discourage collaboration between teams, as individuals start optimizing for velocity metrics instead of value delivery.

Velocity is only meaningful in the context of the team that generated it. Its real purpose is to help that team understand how much they can typically complete in an iteration and use that knowledge to plan future work.

When used correctly, velocity helps create sustainable flow and realistic commitments.

When used for comparison, it distorts the purpose entirely, turning a helpful planning tool into a misleading performance metric.

Why “No Estimates” Can Be Risky for New or Low-Maturity Teams

Skipping estimation entirely—what some call the “no estimates” approach—can sound appealing. It promises to reduce waste and focus purely on delivering value.

But for teams that are new to Agile or still building their delivery discipline, removing estimates too early can actually backfire.

Estimation, when done well, isn’t just about predicting delivery—it’s a learning process. It forces teams to discuss the scope, clarify assumptions, understand complexity, and think critically about dependencies.

Without that structured conversation, teams may miss subtle risks, underestimate unknowns, or skip the alignment that estimation naturally encourages.

Technically, estimation is especially important when a team lacks historical delivery data.

Velocity, cycle time, or throughput metrics only become reliable once a team has built a track record.

Until then, estimates help provide a temporary structure for planning, prioritization, and forecasting.

They offer a shared baseline for product owners to make informed trade-offs and help the team avoid taking on more than it can handle.

When newer teams avoid estimates altogether, they often rely on gut feelings and ad hoc work intake, which increases the chances of overcommitment, context switching, and uneven flow.

Estimates also act as a calibration mechanism for early-stage Agile teams.

Through relative sizing, planning poker, and velocity tracking, teams begin to develop a shared understanding of what “small,” “medium,” or “complex” really means in their context.

This alignment builds over time and supports better forecasting and trust with stakeholders. Without estimates, these learning loops are lost.

The result is not more agility, but less structure, less predictability, and more chaos disguised as flexibility.

Chapter by Chapter

Chapter 1 – The Purpose of Planning

Mike Cohn starts the book with a clear message: planning is hard, but that doesn’t mean we can skip it.

He points out that teams often fall into two traps—doing no planning at all or putting so much effort into planning that they begin to believe their plan is flawless.

Both extremes are dangerous. Instead, he proposes a more balanced view, where planning is seen as a valuable activity, not just a static document.

Why planning matters

Even though plans are often wrong, we still need them. Organizations rely on plans to coordinate marketing, training, staffing, and releases. But beyond these practical needs, Cohn argues that planning is really about figuring out what we should build.

We can’t make that decision all at once—it’s something we discover and refine over time. That’s why planning should be an ongoing, adaptive process, not a one-time event.

Reducing risk and uncertainty

A big part of planning is about surfacing risks early. When we start estimating, we uncover uncertainties—like integrating with a legacy system we don’t fully understand.

These discussions help teams decide whether to investigate further, adjust estimates, or even drop risky features. Planning also helps us refine our understanding of the product as we learn more.

According to Cohn, the biggest risk on most projects is building the wrong thing—and traditional planning doesn’t help us avoid that. Agile planning does, because it encourages us to adjust as we go.

Helping with decision making

Plans support better decisions. Without estimates, we can’t assess the cost, time, or value of a project. If we’re comparing two potential projects, we need estimates to understand which one is more valuable or realistic.

Planning also helps balance tradeoffs—like deciding whether a feature is worth delaying the release, or whether adding a team member would speed things up enough to justify the cost.

Building trust and communicating expectations

Reliable estimates build trust between the team and stakeholders. They make it easier to prioritize, make tradeoffs, and plan releases. They also help developers work at a sustainable pace, which leads to better quality—and fewer bugs mean fewer surprises. Plans also communicate intent.

A good plan doesn’t just give a delivery date; it shows assumptions, priorities, and a strategy for tracking progress. It helps people understand what’s likely to happen and why.

What makes a good plan

A good plan is one that’s reliable enough to support decisions. Early on, that might mean something broad—like saying a product will ship in Q3 with certain key features.

Later, the plan becomes more detailed. Even if things don’t go exactly as planned, the plan can still be useful if it’s updated frequently and reflects what’s actually happening on the project.

What makes planning agile

Agile planning is less about creating perfect plans and more about embracing change. Cohn makes a strong point: a good agile plan is one we’re happy to change when we learn something new. That could mean dropping a feature, changing priorities, or even adjusting the schedule.

Agile planning is spread across the project timeline—starting with release planning and followed by multiple rounds of iteration planning. The key is staying flexible, continuously learning, and using that knowledge to improve the plan.

In the end, Cohn reminds us that planning is about learning. The plan itself might get thrown out, but the thinking behind it is what really matters. Agile planning works because it focuses on that learning, helping teams stay aligned, make smart choices, and build better products—one decision at a time.

Chapter 2 – Why Planning Fails

This chapter takes a closer look at why traditional planning often fails, even when teams have good intentions. Mike Cohn opens with a reality check: most software projects don’t go according to plan.

Costs spiral, schedules double, and many features end up unused. Rather than blaming the teams or tools, he argues that the real issue lies in how we approach planning itself—and outlines five core reasons why our plans break down.

Planning by activity instead of by feature

One of the biggest problems is that traditional plans focus on activities, not features. A Gantt chart might show when each task is supposed to happen—like design, coding, or testing—but this doesn’t reflect what the customer actually values. Customers care about features, not whether someone finished a task.

Cohn points out that this kind of planning also makes it easy to overlook missing features and encourages teams to prioritize task completion over delivering usable software.

Activities don’t finish early, but delays cascade

Here’s where human nature kicks in. If someone sees they’ve been given five days to finish a task, they’ll usually take five days—even if they could’ve finished in three. That’s Parkinson’s Law: work expands to fill the time available.

On top of that, early finishes rarely help, because starting the next task early depends on multiple things going right. Meanwhile, a single delay can push everything back. Delays ripple through activity-based schedules, making it nearly impossible to catch up.

Activities aren’t independent

Unlike flipping coins or digging a basement and painting walls—where one task doesn’t affect another—software tasks are usually linked.

If one screen takes longer than expected to build, others probably will too. Yet many teams act as if the work will somehow “balance out.” This is wishful thinking, not planning.

Multitasking makes things worse

Multitasking seems like a smart workaround when projects fall behind, but Cohn shows how it backfires. When people juggle multiple tasks, their productivity drops sharply.

Not only does switching between tasks waste time, but it also means that nothing gets finished quickly, and features stay half-done for longer. Worse, the illusion of progress can hide the delays until it’s too late to fix them.

Lack of prioritization and ignoring uncertainty

Another issue is building features without considering their value. Traditional plans assume everything will get done, so there’s no effort to work on the most important features first. Then, when time runs out, teams may end up dropping high-value features just because they were scheduled late.

Cohn also criticizes how plans often ignore uncertainty—assuming all requirements are clear and won’t change. But users evolve their thinking, and teams discover new technical challenges. Agile planning deals with this by working in short iterations and revising the plan often.

Estimates become commitments

Finally, Cohn explains a subtle but dangerous trap: treating estimates as promises. An estimate always carries a probability—it’s not a guarantee. But when teams are held to those numbers as if they’re commitments, it creates pressure and fear. Real planning should allow teams to assess risk, update their understanding, and adjust accordingly.

In the end, Cohn paints a clear picture: traditional planning fails because it ignores the real dynamics of software development—uncertainty, human behavior, and changing priorities. Agile planning, on the other hand, faces these challenges head-on, helping teams stay adaptive and focused on delivering value.

Chapter 3 – An Agile Approach

Mike Cohn opens this chapter by highlighting the roots of the Agile movement, starting with the Agile Manifesto created in 2001.

This manifesto introduced four key values that still guide Agile teams today: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.

These values lay the foundation for how Agile teams approach not just software development, but also planning and estimating work.

Working as one team

Agile teams function as a single, collaborative unit. There’s no room for handing off work between roles like analysts, designers, developers, and testers as if they were on separate assembly lines. Everyone shares the same goal and is responsible for delivering value together.

Cohn defines a few key roles: the product owner, who prioritizes and ensures alignment with the product vision; the customer, who funds or buys the product; and the developer, a broad term that includes programmers, testers, designers, and more.

Agile also redefines the role of the project manager, focusing more on leadership and support than command and control.

Short iterations and real results

Agile projects are built around short, timeboxed iterations, typically 1–4 weeks long. Within each cycle, teams complete a set of features that are not just coded, but also tested and ready to release.

Even if the product isn’t shipped after every iteration, it should always be in a potentially shippable state.

These working increments allow for constant feedback and help ensure that development stays on track with what users actually want.

Prioritizing business value

Unlike traditional methods that often develop features in an arbitrary or technically convenient order, Agile teams focus on delivering high-priority features first.

This is guided by the product owner, who creates a release plan based on the team’s capacity and a ranked list of user stories. Cohn introduces user stories as a lightweight way of capturing requirements from the user’s perspective.

These stories are intentionally simple, focusing more on conversations than documentation. The idea is to delay detailed analysis until it’s really needed, keeping the team focused and flexible.

Inspecting and adapting as you go

Agile planning is built on the understanding that things will change—and that’s okay. Plans are treated as a snapshot in time, not a contract carved in stone.

At the start of each new iteration, the team reflects on what they’ve learned and updates the plan. This could be a shift in scope, a realization that estimates were off, or new insights from users. Agile doesn’t encourage chaos, but it does support intentional course corrections that improve the outcome.

Planning happens on multiple levels

Cohn introduces three core layers of planning: release planning, iteration planning, and daily planning. Release planning looks a few months ahead and sets the broad direction. Iteration planning focuses on the next 1–4 weeks, and daily planning—often through standups—keeps the team aligned on a day-to-day basis.

This approach reflects the idea that we can’t see beyond the horizon, so we need to check and adjust often. The further out we plan, the more room we need for adjustments.

Conditions of satisfaction

A key concept introduced here is conditions of satisfaction—the criteria that define success from the product owner’s point of view.

These can include delivery dates, scope, quality levels, or specific features. At both the release and iteration level, teams collaborate with the product owner to find realistic ways to meet these conditions. If not all conditions can be met, the product owner may need to adjust priorities.

Cohn gives an example of a travel booking feature, where the product owner’s conditions include refund rules and confirmation emails. These discussions help clarify expectations before the team starts coding.

In essence, this chapter explains what an Agile approach really means—not just for building software, but for planning it. Agile teams work in short cycles, stay focused on delivering business value, and adapt their plans based on new information.

Rather than pretending to know everything from the start, Agile planning is about learning continuously and adjusting wisely.

Chapter 4 – Estimating Size with Story Points

In this chapter, Mike Cohn introduces story points as a core Agile practice for estimating the size of user stories. The idea is simple but powerful: instead of estimating in hours or days, Agile teams use a relative scale—like small, medium, or large—to describe how big or complex a piece of work feels.

Think of it like ordering food at a restaurant. You don’t need to know the exact number of ounces in a bowl of soup—you just know a bowl is more than a cup and less than a pot.

That’s how story points work: they focus on comparative size rather than precision.

Story points are relative, not absolute

Story points represent the overall size of a task, taking into account not just the effort involved, but also complexity, risk, and uncertainty. A story with 2 points should feel about twice the size of a 1-point story, and half the size of a 4-point story.

There’s no fixed rule on what “1 point” means—what matters is that the team consistently uses the same baseline. Some teams start by picking a small, simple story and calling it a 1. Others choose a medium story and label it a 5. From there, every other story is estimated in relation to the ones already scored.

A practical example—dog points

To make this clearer, Cohn uses a playful analogy: estimating dog breeds using “dog points” based on their height. A Great Dane might get 10 points, a Labrador 5, and a Dachshund just 1.

There’s no need to know the exact height—just how they compare. If you’re unsure (like when estimating a vague user story), you make your best guess based on averages or assumptions.

The same happens with user stories that aren’t fully detailed yet: you estimate based on what you know, and refine later as needed.

Velocity gives story points real value

Story points on their own don’t tell you how long a project will take. That’s where velocity comes in. Velocity is the number of story points a team completes in an iteration. If a team finishes 15 points in a two-week sprint, that’s their velocity.

Now if your project totals 90 points, you can estimate duration by dividing size by velocity—in this case, six sprints or twelve weeks. Cohn stresses that velocity emerges over time. You don’t need to get it right on day one. As the team works, it becomes clear how fast they move, and estimates become more grounded in reality.

How velocity corrects early estimation errors

A major strength of this system is that errors correct themselves over time. Suppose you estimate a project at 200 story points, thinking you can do 25 per iteration. You plan for eight iterations. But after two sprints, it turns out your real velocity is only 20.

You don’t need to re-estimate every story—you just adjust the timeline. That’s the power of separating size estimation from time estimation. The story points don’t change; only your understanding of how quickly you can complete them does.

Effort versus duration

Cohn uses one last example to make this distinction stick. Imagine you’re hired to paint a house. Based only on the floor plan, you estimate effort based on room sizes. You assign values: small bedrooms get 5 points, the master bedroom gets 10.

Even if you later discover the rooms are twice as big as you thought, your relative estimates still hold—they’ll just take more time. You didn’t estimate how long it would take; you estimated how big each task was. Once you start painting and learn your actual speed, the rest falls into place.

By the end of this chapter, it’s clear that story points offer clarity without false precision. They help teams move faster, adapt to change, and build better plans—all without obsessing over exact hours. What matters isn’t how long a task takes, but how it compares to the rest. And that’s the mindset that makes Agile planning work.

Chapter 5 – Estimating in Ideal Days

In this chapter, Mike Cohn introduces ideal days as another way to estimate work—one that focuses on how long something would take in a perfect world.

He explains the idea through a simple analogy: an American football game has four 15-minute quarters, which makes it 60 minutes of ideal time. But anyone who watches a game knows it actually takes closer to three hours of elapsed time to finish.

The distinction is key. Ideal time strips away all the distractions and interruptions. Elapsed time is what really happens.

Why ideal days make estimation easier

Cohn argues that estimating in ideal time is usually easier and more accurate than trying to factor in all the chaos of real life. If you’re asked how long it takes to complete a user story, you could say “one day” based on the actual focused work needed—ignoring emails, meetings, bugs from other teams, or side conversations.

That’s your ideal day. Estimating in elapsed time would mean trying to guess how long the work will actually take on the calendar, which gets messy fast because of all the unpredictable overhead.

Ideal time in software development

In real projects, the gap between ideal and elapsed time is filled with things like sick days, support calls, meetings, and interruptions. Cohn even references research showing that managers average only five minutes of work between interruptions.

Developers may do slightly better, but even so, multitasking and distractions are a real drain. So when someone estimates something as “five days,” it might take two full weeks in elapsed time.

If we estimate in ideal days, we get a cleaner picture of the actual effort needed—then adjust for real-world conditions later when planning the schedule.

Ideal days as a measure of size

This is a crucial point: ideal days can be treated as a measure of size, just like story points. When we say a story will take “three ideal days,” we’re talking about how big the story is in pure effort terms.

The actual time it takes to deliver might be longer depending on the team’s environment, but the size estimate remains the same. That’s what makes it useful for planning and comparison.

Once you know the team’s velocity in ideal days (i.e., how many ideal days of work they complete per iteration), you can calculate how long the project will take.

One estimate per story, not per role

Cohn also advises teams to avoid splitting estimates by role. Instead of saying, “this story takes 2 ideal days from the developer and 1 from QA,” just say the story takes 3 ideal days in total.

This reinforces a sense of shared ownership and keeps planning simple. Splitting by role adds unnecessary complexity—unless there’s a very specific reason to do it, like multiple platform teams who can’t switch roles. In those rare cases, the extra effort might be justified, but it’s usually more efficient to stick to a single estimate per story.

At its core, this chapter reinforces a practical truth: ideal days give us a way to estimate cleanly, focusing only on the effort involved, without getting lost in unpredictable details.

They help teams stay aligned on what needs to be done and let velocity reveal how quickly it gets done. It’s a simpler, more realistic way to plan in an unpredictable world.

Chapter 6 – Techniques for Estimating

This chapter is all about how to estimate effectively without falling into the trap of false precision. Mike Cohn begins with a simple idea: you don’t always need a perfect estimate—just one that’s good enough for the decision at hand.

He compares this to washing a car: you can do it yourself in an hour and get a good result, or hire professionals to spend four hours detailing it.

The second option is more thorough, but often not worth the extra effort. The same logic applies to estimating: more effort doesn’t always lead to significantly better accuracy. In fact, Cohn shows that after a certain point, extra time spent estimating gives you diminishing returns.

Estimates have a purpose, not perfection

A core lesson in this chapter is that we should tailor the effort we spend estimating to the purpose of the estimate. If we’re just deciding whether to send someone a box of cookies, a rough guess is fine.

But if the estimate will influence a build-vs-buy decision, we may need a more thoughtful range. Still, even the most detailed estimate is just that—an estimate.

Cohn includes a figure showing that a little effort can get you reasonably accurate, and that more effort beyond a certain point adds very little and may even reduce accuracy due to overthinking or irrelevant detail.

Estimates are shared responsibilities

Cohn stresses that estimates should be created collaboratively. While it’s true that people doing the work tend to give more accurate estimates, on Agile teams we often don’t know who exactly will do the task.

That’s why it’s best to involve the whole team—everyone brings a perspective that could catch missing details or challenge assumptions. Collaboration not only improves accuracy but also helps align the team on what the work involves.

Choosing an estimation scale

Next, he dives into estimation scales, and why choosing the right scale matters. Humans are better at comparing things within the same order of magnitude—like estimating distances between places in your town. That’s why non-linear scales like 1, 2, 3, 5, 8 or 1, 2, 4, 8 work well.

These scales recognize that the uncertainty grows as size increases, and force teams to avoid false precision (like saying something is 66 instead of 67).

Including 0 can be helpful for truly trivial work that shouldn’t inflate the team’s velocity. For larger stories, Cohn adds 13, 20, 40, and 100, but advises against splitting hairs with too many in-between values.

Estimating epics and themes

Cohn explains that while it’s ideal to break stories into small, similarly sized chunks, sometimes we need to work with epics (very large stories) or themes (groups of related stories). These are useful when we need rough estimates for high-level planning without investing too much effort upfront.

However, we must remember that estimates for larger stories are less reliable, and that stories expected to be worked on soon should be small enough to fit into a single iteration.

Three estimation techniques

He introduces three core techniques for deriving estimates:

• Expert Opinion: Ask someone with experience to give a gut-feel estimate. It’s quick and surprisingly effective, especially when time is tight.
• Analogy: Compare the new story to previously estimated stories. If it’s about twice as big as one you did earlier, estimate it as such. This method, called triangulation, improves accuracy through pattern recognition.
• Disaggregation: Break large stories into smaller ones that are easier to estimate. This avoids vague comparisons like “Is this 50 times harder than that?” and helps catch forgotten tasks. But be careful—not every detail needs to be broken down, or you risk complexity overload and wider estimate ranges.

Planning Poker: A powerful technique

The highlight of the chapter is Planning Poker, a widely used Agile estimation method that blends expert opinion, analogy, and discussion into one engaging activity.

Everyone on the team gets a deck of cards with values like 0, 1, 2, 3, 5, 8, etc. A moderator reads a user story, answers clarifying questions, and then everyone secretly chooses a card.

All cards are revealed at the same time, and any major differences are discussed—especially between the highest and lowest estimates. The process repeats until the group reaches consensus.

Planning Poker works well because it involves cross-functional perspectives, encourages just enough design discussion, and produces fast, collaborative, and reasonable estimates.

Cohn even suggests using a two-minute sand timer to keep discussions focused. Teams can play in full or split into smaller groups as long as they calibrate their understanding of the scale beforehand.

In short, this chapter equips teams with practical tools to make estimation collaborative, quick, and useful—not an over-engineered task.

By combining smart techniques with just enough effort, Agile teams can produce estimates that are good enough to make solid decisions, while keeping energy focused on building real value.

Chapter 7 – Re-Estimating

This chapter tackles a common question in Agile teams: “When should we re-estimate a user story?”

Mike Cohn starts by clearing up a misconception—story points and ideal days are not about how long a task took, but about its size. They represent how big or complex a feature is, not the time it takes to build.

Time is influenced by both the size of the work and the team’s velocity. So, if a story takes longer than expected, that doesn’t necessarily mean it was mis-estimated—it might just reflect a slower iteration.

Don’t re-estimate based on how long something took

Cohn emphasizes that we should only re-estimate if our opinion of the story’s relative size has changed. He uses a fictional project called SwimStats to illustrate the point.

Let’s say you estimated four stories at 3 points each. After completing the first two, the team feels those stories were more work than expected, so they double the estimates to 6 each. That bumps up their velocity to 12 instead of 6.

But then they also need to double the estimates for the remaining stories to stay consistent. Nothing has changed in terms of actual progress.

This shows how changing estimates without changing your opinion of size does nothing—it just moves numbers around. Velocity naturally compensates for those early misjudgments, making it the “great equalizer.”

When to re-estimate: only when the size really changed

Cohn shows a better case for re-estimation. Say you finish a story that involved creating charts and realize it was way more complex than expected. If you’ve got other charting stories coming up, and you believe they’ll be similarly tough, that’s the right time to update the estimates.

But the key is that your understanding of the relative size of those stories has changed—not just how long one of them happened to take. If you don’t update the related stories, your upcoming iteration plans may become unrealistic. That’s the danger of not re-estimating when the pattern of difficulty becomes clear.

Avoid mixing old and new estimates

A big mistake, Cohn warns, is mixing updated estimates for completed stories with original estimates for upcoming ones. It throws off the math.

If you re-estimate a finished story but not the rest, you create a false sense of higher velocity—and start planning based on faulty assumptions. Instead, if you update one estimate because your understanding of size has shifted, you should update the related stories too.

Partial stories and taking credit

What if you only finished part of a story? Cohn shares his preference: either the whole story is done and you take full credit, or it’s not and you take none. This keeps things simple and avoids endless debates. In the next iteration, if the rest of the story is completed, the team’s velocity will balance out.

However, if the leftover work won’t be picked up soon, it’s okay to split the story into two: one part for what’s been done and one or more new stories for what remains. The sum of the new estimates doesn’t need to match the original estimate exactly—what matters is that they reflect current understanding.

Re-estimating is a learning opportunity

Cohn wraps up with an important mindset shift: don’t stress about re-estimating. If something feels off, adjust just enough stories to bring things back in line. Use those moments to learn and refine your future estimates. As he quotes Tom Poppendieck, “Failure to learn is the only true failure.”

In the end, the rule is simple: re-estimate when the story’s size has changed in your eyes—not just because it took longer than you hoped. Let velocity smooth out the bumps, and focus on keeping your estimates consistent, relative, and helpful for making better decisions.

Chapter 8 – Choosing Between Story Points and Ideal Days

In this chapter, Mike Cohn compares two common ways of estimating in Agile: story points and ideal days. Both can be used to estimate the size of user stories, and both are valid.

But they have different characteristics, and choosing the right one depends on the team’s goals and environment.

Cohn doesn’t present one as universally better—though he clearly prefers story points—but rather explores the pros and cons of each to help teams make an informed choice.

Why story points can be more powerful

Story points offer several advantages. First, they promote cross-functional behavior. Since story points represent the total effort required by the whole team, they encourage team members to think collectively instead of just estimating “their part” of the work.

That simple shift—from “I’m a tester on this project” to “I’m part of the team building this story”—can improve collaboration across roles.

Another big plus is that story points don’t decay over time. If a developer becomes more skilled, a story still has the same number of points, because the size of the work hasn’t changed—only their ability to do it faster.

With ideal days, however, that estimate might shrink as the developer improves, which can distort the team’s velocity and make progress harder to track. This makes story points a more stable, pure measure of size.

They’re abstract enough to avoid being tied to actual time, which also keeps them from being misused by managers who might expect teams to “fit more ideal days into a week.”

Cohn also points out that estimating in story points is usually faster. Because teams focus on relative sizing, they can compare stories without getting lost in details.

There’s less temptation to break stories into tasks and overanalyze. And finally, story points are consistent across team members.

Your ideal day and mine may look very different—but if we agree a story is about the same size as another one we did earlier, we can estimate it the same way regardless of our personal speed.

Why ideal days can be helpful—especially early on

Despite his preference for story points, Cohn acknowledges that ideal days have their place. For one, they’re easier to explain to people outside the team.

Saying “this would take two full days if I worked on it with no interruptions” is more intuitive than “this is a 3-point story.” Ideal days also feel more natural at first.

When teams are just starting with estimation, they often find it easier to anchor to something they already understand—like days—before getting used to abstract comparisons.

Another benefit is that ideal days can make velocity predictions easier—especially at the beginning of a project, when no real data is available. Since ideal days already feel tied to time, teams can make an educated guess about how many ideal days they’ll complete in a sprint.

This helps with planning until velocity becomes more stable.

The recommendation: Start where you are, move toward story points

Cohn’s recommendation is clear: story points are usually the better long-term approach. They foster team alignment, abstract away from the pressure of time, and make it easier to improve estimation over time. But if a team struggles to separate size from time, it’s okay to start with ideal days.

Cohn shares that he often helps new teams begin with ideal days and then gradually nudges them toward story points—simply by asking questions like, “Is this story bigger or smaller than the last one we estimated?”

The ultimate goal is to help teams think in relative size, not in units of time. Once that mindset clicks, the switch to story points becomes natural—and often unnoticed.

In summary, this chapter isn’t just about choosing between two techniques. It’s about helping teams evolve their understanding of estimation. Both approaches can work, but story points encourage healthier, more Agile behaviors. They shift the focus from deadlines to value, from individual roles to team effort, and from fixed predictions to adaptive learning.

Chapter 9 – Prioritizing Themes

This chapter focuses on a key reality in Agile planning: we can’t build everything, so we need to prioritize what gets done.

Mike Cohn begins with a simple truth—there’s never enough time or budget for every idea. The job of deciding what’s most important falls largely to the product owner, but it’s a shared responsibility involving the whole team.

Rather than ranking every tiny story individually, the process often starts by grouping stories into themes—sets of related features that deliver user or customer value—and then ranking those themes.

Beyond just business value

We often hear the phrase “prioritize based on business value,” but Cohn argues that’s too vague to be useful on its own. He introduces four specific factors that give us a more practical way to prioritize:

1. Value – How much financial return or impact the feature will bring.
2. Cost – How expensive it will be to build or support the feature.
3. New knowledge – What the team will learn by building it (about the product or the project).
4. Risk – What risks are reduced by delivering the feature early.

Understanding value and cost

Financial value is often the easiest starting point. If you know one theme could bring €200,000 in new sales and another might bring €150,000, it’s clear which one has higher value. But estimating that value is often complex and uncertain, involving sales forecasts, timing, and assumptions.

If precise financial value isn’t available, desirability to users can be used as a proxy—something Cohn explores further in the next chapters.

Cost, meanwhile, is equally important—and not always obvious. A feature might be cheaper to implement now than later, but that doesn’t automatically mean we should build it today.

If it changes dramatically over the next few months or introduces complexity too early, we could end up wasting effort. Cohn suggests doing rough cost estimates based on story points or ideal days converted into monetary value.

For example, if 120 story points cost €150,000 over 12 weeks, each point costs €1,250—and a 30-point feature would be worth a €37,500 investment.

Knowledge and learning as priority drivers

New knowledge is often undervalued but incredibly useful. Agile teams gain both product knowledge (what features are valuable and needed) and project knowledge (how to build them, with what tools, and how the team works together).

Cohn references the idea of “end uncertainty” (what we should build) and “means uncertainty” (how we’ll build it). Waterfall tries to eliminate the “what” upfront, but Agile acknowledges that both types of uncertainty are reduced gradually and iteratively.

Working on certain features early can generate valuable feedback and help refine the product direction faster.

Risk: The silent factor that can’t be ignored

Cohn treats risk as a close cousin to knowledge. High-risk items are those that could derail a project if they fail—like technical unknowns, vendor dependencies, or hard-to-implement features.

He presents a helpful model: features can be high or low in both value and risk. High-risk, high-value features should come first, because they offer the biggest payoff and the biggest danger if ignored. High-value, low-risk features can come second.

Features with low value but high risk should be avoided or deferred—there’s no point in tackling risky work if it doesn’t help much.

Bringing it all together

Cohn suggests starting prioritization by looking at value vs. cost to get an initial order. Then, adjust based on learning and risk. A feature with medium value and cost might get bumped up if it removes a major risk or generates crucial insight.

This doesn’t have to be a spreadsheet exercise—often, it happens naturally in the product owner’s head. But it’s helpful to be conscious of what’s influencing those decisions.

Applying the framework: infrastructure and UI examples

To bring the framework to life, Cohn walks through two examples: infrastructure (like security frameworks) and user interface design. Infrastructure may not seem valuable on its own, but it often reduces risk and can uncover technical knowledge—so it might be worth doing earlier.

On the other hand, early UI work can help reduce the risk of building the wrong product. It generates feedback, enhances usability, and improves alignment with real user needs.

In summary, this chapter reframes prioritization as more than just sorting features by value. It’s about balancing value, cost, learning, and risk.

Agile teams that consider all four factors will make smarter decisions about what to build next—and they’ll be much more likely to deliver something truly valuable, on time, and with less waste.

Chapter 10 – Financial Prioritization

In this chapter, Mike Cohn dives into a more analytical approach to prioritization—using financial metrics to make better product decisions. The idea is straightforward: if we can estimate how much money a theme will make or save, we can prioritize work based on real value.

This might sound a bit corporate, but it’s incredibly practical—especially when you have more good ideas than resources to build them.

Estimating returns the right way

Cohn suggests starting with a meeting that brings together people from product, development, marketing, and sales to estimate the financial return of each theme.

The team fills out a worksheet that forecasts value across categories and quarters—typically over a two-year span. He introduces a simple but flexible return model with four categories:

• New revenue: From acquiring new customers
• Incremental revenue: From existing customers spending more
• Retained revenue: From preventing customer loss
• Operational efficiencies: From saving internal time or costs

These categories cover most types of business value and give teams a framework to start quantifying benefits, even if the data isn’t perfect.

The point isn’t precision—it’s getting a shared, directional understanding of where the value lies.

A working example: WebPayroll

To bring this to life, Cohn uses a detailed example of a fictional company, WebPayroll, which plans to offer overnight payroll processing.

The feature is estimated at 150 story points, and with a team velocity of 20 points per iteration, it will take about 8 iterations to build.

He walks through each source of value:

• New revenue: Gained from customers who previously rejected the 3-day processing limitation.
• Incremental revenue: Extra money from current customers upgrading to the overnight feature.
• Retained revenue: Preventing customer churn by adding a more competitive feature.
• Operational efficiencies: Savings from not hiring extra payroll clerks, thanks to automation.

Each category is mapped to quarters and filled with numbers—based on sales projections, average revenue per user, and expected efficiencies.

Development cost and cost per story point

Then comes the cost side. Using salaries, time on the project, and a 50% labor burden, Cohn calculates a cost per iteration of €13,500 and a cost per story point of €675.

This allows the team to estimate that the 150-point feature will cost around €101,250 in total.

Making it real with financial metrics

With cash flows estimated for each quarter, Cohn introduces four classic financial metrics:

• Net Present Value (NPV): Total value of the project in today’s money, after discounting future returns. For the WebPayroll project, the NPV is €46,341 using a 12% annual discount rate.
• Internal Rate of Return (IRR): The project’s return expressed as a percentage. It tells you how quickly the investment grows in value. For WebPayroll, the IRR is 12%, meaning the cash flow is equivalent to a 12% annual return.
• Payback Period: How long it takes to recover the initial investment. For WebPayroll, the break-even point is 7 quarters.
• Discounted Payback Period: Same as above, but factoring in the time value of money. Still 7 quarters for WebPayroll.

Cohn includes a comparison of three themes: overnight service, custom reporting, and partner integration. Each has different costs, NPVs, ROIs, and payback periods.

The decision isn’t clear-cut—it depends on your goals. Is faster payback more important than total return? Are you limited in team availability? Are some themes more urgent from a strategic point of view?

This chapter shows that financial thinking doesn’t have to be dry or disconnected from Agile.

In fact, it enhances Agile’s emphasis on delivering value. When you can tie themes back to real business benefits, you’re not just building software—you’re making smarter bets with your team’s time and energy.

Cohn closes with a reminder: modeling financial return doesn’t have to be perfect—it just needs to help you make better decisions. Estimate broadly, use the best data available, and compare themes side by side using tools like NPV and ROI. It’s not about finding a perfect number.

It’s about finding the confidence to say, “This is what we should build next.”

Chapter 11 – Prioritizing Desirability

In this chapter, Mike Cohn explores how to prioritize features not just by value and cost, but by how much users actually want them.

He introduces two practical methods to assess desirability: the Kano Model and Relative Weighting.

These tools help Agile teams move beyond gut feelings and bring more structure to deciding which features are most important to users.

The Kano Model: What really satisfies users

Cohn begins with a personal example—his hotel room. Some features, like a bed and bathroom, are must-haves. Others, like a larger room or gym, are “the more the better.”

And a few, like a TV on the treadmill or free bottled water, are delightful surprises. He uses this story to introduce the Kano Model, which groups features into three categories:

• Must-haves (Threshold) – Basic expectations. Without them, users are dissatisfied. But adding more doesn’t make them happier.
• Linear Features – The more you have, the happier users get. Think bigger, better, faster.
• Exciters and Delighters – Unexpected features that surprise users. They don’t ask for them, but once they experience them, they love them.

What’s powerful here is the idea that different types of features impact satisfaction in different ways. You can’t just stack up a bunch of “more of the same” and expect wowed users.

You need a mix—and knowing what fits into which category helps with smarter prioritization.

How to use the Kano Model in practice

Cohn explains that the easiest way to apply Kano is to ask users two simple questions about each feature:

1. How would you feel if the feature were present?
2. How would you feel if the feature were absent?

Each question is answered on a 5-point scale, from “I like it” to “I dislike it.” By cross-referencing the answers, you can classify features into the right Kano category.

You don’t need huge surveys—Cohn says even 20–30 users can give you solid insights. And when different user groups give different answers, you might want to segment your results by role, company size, or other key traits.

Relative Weighting: A quicker alternative

For teams that don’t want to run surveys, Cohn introduces Relative Weighting, a method developed by Karl Wiegers. Here, you work as a team to assess each feature on:

• Relative benefit if included
• Relative penalty if excluded

You rate both on a scale of 1 to 9, then add them up to get a total value. From there, you compare that value against the estimated cost (in story points or ideal days).

The result is a priority score: value divided by cost. Features with the highest ratio should be built first, since they provide the most return for the least effort.

Cohn illustrates this with features from the fictional SwimStats site, showing how something with a modest benefit but a very low cost might outrank a flashy but expensive feature.

He also shares a humorous real-life example: a compliance feature with no benefit—but a massive penalty if ignored (i.e., the CEO could go to jail). That’s a solid 9 on penalty.

The importance of penalty

Cohn warns against skipping the penalty column. Sometimes a feature doesn’t drive new revenue, but it’s still critical. Considering both benefit and penalty gives a more complete picture—and often uncovers features that would otherwise be overlooked.

This chapter shows that desirability isn’t just about what users say they want—it’s about understanding what will satisfy them, surprise them, and prevent dissatisfaction.

Whether you use Kano surveys or Relative Weighting discussions, the goal is the same: to make better prioritization decisions based on real user impact. Agile planning isn’t just about building fast—it’s about building what matters most.

Chapter 12 – Splitting User Stories

In this chapter, Mike Cohn tackles a practical challenge every Agile team faces: how to split large user stories into smaller, more manageable ones.

Not every story starts “iteration-ready,” and trying to cram an oversized story into a sprint usually leads to trouble.

So, Cohn gives us not just one way to split stories, but a toolkit of strategies—each illustrated with real examples and paired with simple guidelines.

When and why to split stories

The first reason to split a story is obvious: it’s too big to fit into an iteration. But even smaller stories might need splitting if there’s not enough space left in the sprint or if the team needs more accurate estimates.

For example, when a product owner had a single 70-point story for a new feature, she didn’t split it—because even if the estimate was off by 100%, she knew the value justified it.

But if she had been on the fence, she could’ve broken it down to sharpen the estimate. So the rule here is: split stories when they’re too big or when better insight is needed.

Splitting across data boundaries

One of the most useful techniques is to split based on data types or levels of detail. Cohn shares a story about a team building a financial app.

They started with a broad story: “As a user, I can enter my balance sheet.” That story included dozens of fields. So they broke it down: first by high-level summary, then by categories (like loans and real estate), and finally by detailed data entry.

The result? A dozen smaller stories, all manageable within a two-week iteration. This approach works in other contexts too—like separating phone number formats or supporting fewer edge cases first.

Splitting on operational boundaries

Another great technique is splitting stories by CRUD operations—Create, Read, Update, Delete. If a coach wants to “manage swimmers,” that one story can easily become three: add swimmers, edit them, and remove them. Similarly, a complex UI can be broken into phases: lay out the form, wire up part of the backend, then implement full interactivity.

Even if the early iterations aren’t usable by real users, they show progress and reduce uncertainty. The key is to split by action or function, not by code layer.

Removing cross-cutting concerns

Sometimes a story gets bloated because it includes too many “extra” concerns—like security, error handling, or logging.

These are important but can be deferred. One example: a search feature that only showed secured results. In the first iteration, they dropped the security filter and added it later. Another: a login screen with strict password rules.

The team created two stories—one for basic login and another for password policies. Cohn makes it clear that you probably wouldn’t release with just the insecure version, but splitting helps the team build in steps.

Delaying performance constraints

Performance can also weigh down a story. So, make it work first—then make it fast. Cohn recalls a stock charting feature that required caching to meet speed goals.

The team built the basic version first, then added caching as a separate story later. This approach works for any non-functional requirement—like memory limits or speed caps. Build the feature, then optimize.

Splitting by mixed priorities

Sometimes one story contains several behaviors—but not all of them are equally important. A login feature might need retries, email alerts, and account locks.

But if the core login is the only must-have, it makes sense to split and prioritize. That way, the team can deliver value sooner without waiting on lower-priority extras.

What not to do: don’t split stories into tasks

Cohn warns against breaking a story into development tasks like “code UI” or “build database.” That’s not real splitting—it’s just assigning work.

A better approach is to “fire a tracer bullet”: build a thin slice through all layers of the system that delivers a small but working piece. It’s more cohesive, visible, and useful than finishing one layer in isolation.

Avoid unrelated changes

Finally, once a story is right-sized, resist the temptation to “just fix one more thing.” It’s natural to want to clean up related code while you’re in there—but every change adds risk and effort.

Stick to priorities and avoid sneaking in extras unless their value justifies it.

Sometimes, combine stories too

Not all stories need to be smaller. For example, a bunch of tiny bug reports can be grouped into one fix-it story. If a story takes just a few hours, it might flow better as part of a larger unit.

Splitting stories is more art than science—but it’s a skill worth mastering. Cohn gives us multiple strategies: split by data type, operations, cross-cutting concerns, performance, or priority.

Just don’t fall back on splitting into tasks. When done well, splitting stories helps teams plan better, show progress earlier, and deliver value faster—one focused slice at a time.

Chapter 13 – Release Planning Essentials

In this chapter, Mike Cohn introduces release planning—a high-level planning process that looks beyond a single iteration.

While iteration planning is about the short term, release planning helps teams and stakeholders see the bigger picture, often covering 3 to 6 months of work.

It connects iterations into a meaningful whole, showing how they align with business goals, market timing, and delivery expectations.

Why release planning matters

There are three main reasons for doing release planning.

First, it helps answer the question: How much can we build and by when?

Second, it sets expectations for stakeholders who need to make decisions based on what’s likely to be delivered and when.

Third, it provides direction—a guiding point for the team, so they’re not just moving from iteration to iteration without a shared sense of where they’re going.

Cohn compares it to hiking: without a visible summit, the path becomes unclear, and progress can feel aimless.

Two approaches: date-driven vs. feature-driven

Cohn explains that releases can be planned in two ways. In a date-driven project, the release date is fixed, and the team determines how many features can be delivered by then. In a feature-driven project, the feature set is fixed, and the team estimates how long it will take to deliver.

In either case, planning is about balancing schedule, scope, and resources—the “conditions of satisfaction” the product owner brings into the room. Usually, one of those factors is the most important, and that helps shape the plan.

The building blocks of a release plan

To build a release plan, the team needs a few things:

1. Estimates for the user stories – Without estimates, it’s like shopping without price tags. Not every idea needs to be estimated—just the ones that might make it into this release.
2. An iteration length – Most teams use 1–4 week iterations. The length affects how often priorities can be adjusted.
3. A velocity estimate – Based on past performance or a forecast, this tells us how much work the team can complete per iteration.
4. A prioritized list of user stories – The product owner prioritizes the stories with input from the team, especially around sequencing.

Once these pieces are in place, the team multiplies iterations × velocity to get the total capacity for the release. Then, they choose the most valuable stories that fit within that limit.

Level of detail: how much is enough?

Cohn makes an important point: a release plan doesn’t need to assign every story to a specific iteration. In fact, doing so too early can be a waste of time, because things always change.

A good compromise is to assign specific stories to the first one or two iterations—especially if the team is starting right away—and treat the rest of the release as a flexible backlog. This provides structure without false certainty.

Planning in action: SwimStats example

To show how release planning works in practice, Cohn walks through a full example using the fictional SwimStats project.

The product owner wants a release in 3 months, so the team plans for six 2-week iterations with a velocity of 8 points per iteration, giving them 48 points of capacity.

They prioritize features, estimate their sizes, and select which stories fit into that budget.

When they realize that one necessary 3-point story would push the release to 49 points, they make a trade-off: drop one 8-point feature to stay on track.

This moment illustrates a key principle of Agile planning—every decision is a negotiation between value and constraints, and the team needs to adjust based on reality, not wishful thinking.

Finally, Cohn reminds us that a release plan isn’t carved in stone. It should be revisited regularly, especially if velocity shifts or priorities change. Many teams update it every few iterations to stay aligned with current conditions.

In short, release planning is about seeing the road ahead just clearly enough to make smart decisions—while staying flexible. By identifying the goals, estimating the effort, and prioritizing what matters most, Agile teams create a roadmap that balances ambition with realism. And they do it in a way that stays grounded in the real pace of progress, not just hope.

Chapter 14 – Iteration Planning

This chapter takes us from the big-picture world of release planning into the day-to-day work of iteration planning—where teams figure out exactly what they’re going to do in the next week or two.

While release planning is about what to deliver over months, iteration planning zooms in on what to build next, and how to actually do it.

What is iteration planning really about?

Mike Cohn begins by making this simple: iteration planning is the team’s chance to get specific. You take a few prioritized user stories and break them down into concrete, actionable tasks.

These tasks might live on cards, in a spreadsheet, or in a digital tool, but what matters is that everyone involved—product owners, developers, testers, designers—is part of the conversation. It’s not just about assigning work; it’s about collaborative understanding.

Cohn advocates for using note cards in physical meetings, especially for co-located teams. Why? Because it invites participation. If one person is typing into a system, they control the narrative. But with cards, everyone can grab a pen, write tasks, and contribute.

This seemingly small change makes the whole planning session more democratic—and more effective.

No task assignments (yet)

A crucial principle here is that tasks aren’t assigned to individuals during iteration planning. Even if it seems obvious who will do what, reality changes quickly in Agile.

Cohn encourages a mindset of shared ownership: everyone’s responsible for getting the stories done, not just their “piece.” This keeps collaboration high and bottlenecks low.

How is iteration planning different from release planning?

Iteration planning looks just a few weeks ahead. Instead of estimating user stories in story points or ideal days, we estimate tasks in ideal hours. It’s more granular, more detailed, and more immediate.

The release plan gives direction; the iteration plan tells us how to take the next step.

Velocity-Driven vs. Commitment-Driven Planning

Cohn introduces two common approaches to iteration planning:

• Velocity-driven means the team picks stories until they’ve filled up their typical velocity. Then, they break them into tasks and estimate.
• Commitment-driven flips it: the team picks one story at a time, breaks it into tasks, estimates those tasks, and asks: “Can we commit to this?” If yes, they pull in the next story and repeat until they reach capacity.

Both methods work, but Cohn clearly prefers commitment-driven. It builds more realistic plans and encourages genuine team ownership. Plus, with fewer stories per iteration, errors in story point estimates can distort the velocity-driven approach. With commitment-driven, teams plan based on real, known work, not guesses.

Breaking down user stories

Once stories are selected, the team splits them into every task needed to go from idea to finished product—coding, testing, UI design, writing acceptance criteria, etc.

He emphasizes including testing tasks early in planning, so testers are fully engaged from the start. If automated tests or bugs are part of the work, they should be listed too.

Sometimes, if a task is especially unclear, Cohn recommends creating a “spike”—a task specifically meant to investigate and reduce uncertainty.

For instance, if the team isn’t sure how a small change will impact legacy code, they might create two tasks: “Investigate impact” and “Make the changes.”

Estimation and collaboration

Tasks are estimated in ideal hours, and Cohn urges teams to do this together—even if someone else will eventually do the work.

That way, you get group wisdom, challenge faulty assumptions, and avoid ego-driven underestimation. Estimates are guesses, not contracts, and the conversation around them is often more valuable than the number itself.

He even covers task size: ideally, tasks should be sized so that a developer can complete about one per day. This keeps work flowing, prevents bottlenecks, and makes daily stand-ups more meaningful.

Handling dependencies and maintenance

Dependencies between stories are common and usually harmless if they follow a natural order. If not, the team needs to add extra tasks to make things work.

That’s fine—it’s just shifting effort, not creating more of it. He also uses a nice metaphor for support work: imagine your iteration is a glass. Support and other commitments fill part of it. Only what’s left over should be planned for new work.

The final message is powerful: what matters most is whether the team can commit to delivering features, not whether they can check off every task.

Estimating tasks helps us understand the work, but real Agile success comes from building usable, working features each iteration. That’s where the value is.

In short, this chapter shows that iteration planning is where strategy meets execution. It’s the bridge between product vision and working software.

And by making it collaborative, flexible, and grounded in real work, teams can stay aligned, focused, and successful.

Chapter 15 – Selecting an Iteration Length

In this chapter, Mike Cohn unpacks a deceptively simple question: how long should an iteration be? Most Agile teams stick to iterations between one and four weeks, but that doesn’t mean there’s a one-size-fits-all answer.

The “right” iteration length depends on your team, project, context, and goals.

Cohn helps teams think through the trade-offs and shares guiding principles to help them find the sweet spot.

What to consider when choosing your iteration length

Cohn lays out seven key factors that should influence the decision:

1. The overall release length – Shorter projects need shorter iterations to ensure enough opportunities to deliver, inspect, and adjust. If your project is just three months, doing one-month iterations gives you only two chances to steer. Ideally, you want at least four or five feedback loops during a release.
2. The level of uncertainty – If you’re not clear about what users need, how fast your team will move, or what tech challenges might emerge, shorter iterations let you learn faster and adapt quickly.
3. The ease of getting feedback – Can you talk to stakeholders informally throughout the iteration? Or do you only get feedback during scheduled reviews? Choose a length that matches how and when people are available to give you meaningful input.
4. How long priorities can stay stable – Once an iteration starts, priorities should hold steady. If things shift often in your environment, shorter iterations help keep the team focused without being constantly disrupted.
5. Willingness to go without feedback – The longer you wait between showing your work to the outside world, the more you risk going off track. Frequent feedback reduces that risk, especially when user needs aren’t well defined.
6. The overhead of iterating – Every iteration has a cost: planning, reviewing, testing, and more. If this overhead is high (especially for teams without strong automation), longer iterations can reduce that burden. But the goal is always to minimize iteration overhead over time.
7. Maintaining urgency – A short iteration keeps the pressure on—but too short, and it becomes stressful. Cohn quotes Niels Malotaux: when deadlines are distant, we relax; when they’re close, we hustle. Iteration length can balance urgency with sustainability.

Cohn’s rule of thumb and preference

From experience, Cohn prefers two-week iterations. They strike a nice balance: short enough to keep momentum, long enough to manage the overhead.

One-week iterations can be too hectic, leaving no time to recover from sickness or surprises. Four-week iterations feel more relaxed at first but can lead to last-minute rushes, uneven pressure, and slower feedback loops.

He also suggests an approach he calls 6×2+1: six two-week iterations followed by a one-week iteration where the team chooses what to work on.

It’s not a vacation week—it’s a chance to pay down tech debt, explore new ideas, or prepare for bigger upcoming work. It gives the team a breather while staying productive and engaged.

Real-world examples: Napa vs. Goodman

To show how context matters, Cohn shares two case studies:

• The Napa project used four-week iterations. It was a long internal project, users were nearby but not always available, and feedback every two weeks would have been too frequent. The team had clear direction, moderate uncertainty, and a strong sense of urgency.
• The Goodman project, in contrast, had high uncertainty, shifting priorities, and a vague target audience. Feedback was hard to get. They chose two-week iterations to enable faster learning, better responsiveness, and a stronger cadence.

Don’t tie iterations to the calendar

Cohn ends with a cautionary tale about avoiding month-end or quarter-end iteration deadlines.

A missed delivery pushed one project’s release from March 31 to April 7, and that single week meant the revenue couldn’t be recognized until the next fiscal quarter—bad news for a public company.

His advice: decouple iteration schedules from financial calendar pressures to avoid surprises and added risk.

Iteration length isn’t about picking a number and sticking to it blindly. It’s about finding a rhythm that helps the team deliver value consistently, get feedback fast, stay focused, and adapt as they learn.

Two weeks often works well—but the best length is the one that fits your project’s reality, not someone else’s rulebook.

Chapter 16 – Estimating Velocity

In this chapter, Mike Cohn explains how to estimate velocity, which is crucial for release planning but often tricky when you’re just starting out.

Velocity is the amount of work a team can complete in an iteration. It’s not a fixed number—it varies over time and across projects.

Cohn shows that while it’s tempting to pick a precise number, it’s much smarter to estimate velocity as a range. After all, it’s better to be “roughly right than precisely wrong,” as he quotes Keynes.

Three ways to estimate velocity

Cohn lays out three practical approaches for estimating velocity:

1. Use historical values – If the team has worked together before under similar conditions, this is the easiest option. But if anything major has changed—team members, technology, tools, or domain—historical velocity becomes less reliable. Even when using past data, Cohn recommends applying the cone of uncertainty: multiply the average by 60% and 160% to create a realistic range. So a team with a past average of 15 might plan using a range of 9–24 points.
2. Run an iteration – This is the gold standard. Instead of guessing, observe what the team actually delivers in one or more real iterations. If the team completes three sprints with velocities of 12, 15, and 16, then you can use that range or calculate an average and apply the cone of uncertainty again. This approach avoids over-planning and gives teams a solid foundation for release estimates.
3. Make a forecast – Sometimes, the team doesn’t exist yet or the project won’t start for months. In these cases, you can’t observe actual velocity. So instead, you forecast it. Cohn walks through a method where you estimate available hours per person, multiply by the number of days in the iteration, and then break down stories into tasks until you fill that time. The total story points from those tasks become your estimated velocity—then again, wrap it in a range.

Estimating availability and filling an iteration

Cohn suggests that most people working full-time on a project have 4 to 6 productive hours a day—not 8. That’s because meetings, emails, and distractions eat into actual work time. So for a team of 4 people working 6 hours/day over 10 days, that’s 240 hours in an iteration.

Then the team selects a mix of stories and tasks that reasonably fit those 240 hours. For example, in the SwimStats case, they picked 25 story points that translated into 221 task hours—close enough to be realistic.

Handling mixed or part-time teams

Not every team has people working full-time on one project. Some team members may be split across initiatives. In these cases, it helps to estimate each person’s daily availability individually, like in a table.

For instance, Sergey might contribute 4 hours/day, while Carina might only contribute 2. Tally up their totals to get a more accurate capacity for planning.

Always wrap velocity in a range

Whether you use historicals, real iterations, or forecasts, Cohn stresses this: never use a single number for velocity. The range accounts for uncertainty and keeps teams from making false commitments.

He recommends starting with a wider range early on (e.g., 15–40), and narrowing it as the team gathers more data.

Which approach should you use?

Cohn ranks the options clearly:

• First choice: Run a few iterations and observe real velocity.
• Second: Use historical data from a similar project and team.
• Third: Forecast by estimating availability and filling the iteration.

And as soon as real data becomes available—switch to using it. Even if you start with a forecast because the project is months away, update it once the team starts working.

Estimating velocity is both an art and a science. It’s about combining logic with humility.

You won’t get it exactly right, and that’s okay. What matters is to ground your plan in reality, use ranges instead of rigid numbers, and evolve your estimates as the team moves forward.

Agile isn’t about knowing everything upfront—it’s about learning as you go and adjusting wisely. Velocity estimation is no different.

Chapter 17 – Buffering Plans for Uncertainty

In this chapter, Mike Cohn addresses a tough reality: not every Agile project happens in a fully flexible environment. Some have tight deadlines, fixed scopes, high uncertainty, or big consequences if things go wrong. In these cases, traditional Agile practices may need reinforcement.

That’s where buffers come in—tools for protecting your plan against uncertainty and for making your commitments more reliable.

Why buffers matter

Some projects need to be planned well in advance. Others are tied to rigid contracts or critical release dates. Sometimes the team isn’t even fully known yet.

In all these cases, being wrong about your plan has a high cost. Cohn shares an example from his time at a Fortune 40 company, where projects were budgeted a year ahead—even before knowing exact team composition. In this kind of environment, adding buffers becomes a risk management strategy.

He introduces two key types:

• Feature buffers, which protect scope
• Schedule buffers, which protect time

Feature buffers: “Must-have” vs. “nice-to-have”

Cohn compares feature buffers to grocery shopping before a game: you focus on the essentials and aim to grab a few extras if time allows.

Similarly, in Agile planning, the product owner selects all mandatory features first. Then, they select 25–40% more “optional” features, depending on the uncertainty level.

The full project is planned as if all features will be delivered, but the optional stories are built last—if time allows.

For example, if the core release needs 100 story points, the product owner might add another 30 as a buffer. The team then plans for 130 points, knowing they must finish the first 100, and can skip the last 30 if time runs out.

This is consistent with DSDM’s MoSCoW rules: Must Have, Should Have, Could Have, Won’t Have—where no more than 70% of the effort goes toward “Must Haves.”

Schedule buffers: Planning like catching a flight

Imagine you need 70 minutes to get to the airport. But what if there’s traffic? Long lines? A missing parking spot?

You leave 100 minutes early, creating a 30-minute schedule buffer. That’s not padding—it’s smart planning.

Cohn applies this metaphor to software projects. You don’t buffer individual tasks—you buffer the whole schedule.

You assume a 50% likelihood for each story estimate, and then you add a buffer to protect the full delivery date.

This reduces risks without inflating every step of the project, and it avoids Parkinson’s Law (work expands to fill the time available) and Student Syndrome (starting too late and rushing at the end).

How to calculate a schedule buffer

Cohn gives two options:

1. The accurate way: Estimate both a 50% likely and 90% likely duration for each story. Then, calculate the difference, square each one, add them up, and take the square root—this is the project buffer. This method accounts for which stories carry more risk.
2. The simpler way: Estimate only the 50% durations, then add a buffer equal to half the sum of those estimates. It’s easier, but less precise, since it doesn’t adjust for the actual uncertainty in each story.

He recommends the first method whenever possible. It’s also more transparent and helps the team and stakeholders understand where the risk really lies.

Combining feature and schedule buffers

Here’s where it gets interesting. Cohn shows that you don’t have to choose one type of buffer—you can combine both. If your deadline is fixed, you can adjust the scope.

If your scope is fixed, you can add time. But if you buffer both, even a little, you gain powerful flexibility. He compares it to having both seatbelts and airbags—each protects against different types of collisions.

He also mentions budget buffers (e.g., hiring 30 people but budgeting for 33). This is more common on large teams, since adding one person to a team of 4 is a big change, but on a 30-person team it’s just a 10% increase.

Avoid confusing buffers with padding

Cohn is clear: padding is arbitrary; buffering is deliberate. Padding is hiding time because you’re afraid of being wrong. Buffers are honest, calculated margins based on real uncertainty.

He uses the analogy of leaving space between your car and the one in front—because you expect to need it. Same with project buffers: they exist to be used.

Important caveats

• Only add schedule buffers if your estimates are at the 50% likelihood level. If you’re already using pessimistic estimates, adding more buffer just inflates the schedule.
• Not all projects need buffers. If you’re delivering continuously without hard deadlines, you can skip this.
• Be transparent. Explain how and why the buffer exists—don’t let it look like lazy overestimation.

Buffers are about making better promises in uncertain environments. Feature buffers help you stay flexible on scope. Schedule buffers help you hit your dates with confidence.

And when you use both wisely, you protect your project—and your reputation—against surprises. Agile doesn’t mean winging it. It means planning smart and being ready for the unknown.

Chapter 18 – Planning the Multi-Team Project

As Agile projects scale up, it’s no longer just about one small team building software—it’s about coordinating many teams working together toward a shared goal. In this final chapter, Mike Cohn brings together everything we’ve learned and applies it to the challenge of planning large, multi-team projects.

He doesn’t propose a rigid framework, but rather a practical, flexible set of four techniques to help multiple Agile teams stay aligned, move efficiently, and avoid delays.

1. Establishing a common basis for estimates

In small projects, teams might get away with using different estimation units. But with multiple teams, that quickly becomes chaos.

Imagine one team using story points and another using ideal days—or worse, both using story points but assigning wildly different meanings to the same number.

Cohn’s solution is simple: pick one unit and calibrate it across teams.

There are two ways to do this:

• Re-estimate past stories as a group to create a shared baseline
• Collaboratively estimate a variety of new stories to align expectations

This shared reference point ensures that estimates are consistent, which makes cross-team planning possible and meaningful.

2. Adding detail to user stories earlier

In small teams, it’s often okay to start a sprint with loosely defined user stories and refine them as you go. But that doesn’t scale well. In large projects with interdependent teams, lack of clarity early on causes friction later.

That’s why Cohn recommends preparing stories in advance—especially identifying the conditions of satisfaction (high-level acceptance criteria) for the stories most likely to be tackled next.

He’s not suggesting an upfront waterfall plan, but rather a lightweight preparation buffer—done by analysts, designers, and product owners—as part of each iteration. This keeps teams in sync while preserving agility.

3. Lookahead planning

Cohn introduces the idea of a rolling lookahead plan—a release plan that constantly evolves and always includes detailed expectations for the next 2–3 iterations.

This is critical when teams have dependencies on each other. For instance, if one team is building an API and another team needs it for their next story, the receiving team can’t confidently commit unless they know the API will be ready.

Planning handoffs between iterations (rather than mid-iteration) is safer and more reliable. Cohn stresses that teams should limit their commitments to completed work, not work that’s “almost done.”

4. Incorporating feeding buffers

Sometimes, a rolling lookahead isn’t enough—especially when interdependencies are complex or frequent. That’s where feeding buffers come in. These are time cushions inserted between dependent deliverables to protect one team from delays in another’s work.

Say Team 1 is building an API, and Team 2 needs it next sprint. If Team 1 plans to finish it at the last minute, that’s risky. Instead, Team 1 should plan a bit of a buffer—delivering earlier than strictly necessary—to give breathing room. It’s not about slacking off; it’s about managing risk proactively.

Feeding buffers can slightly lengthen the overall timeline, but they make delays less likely—and that’s a trade worth making in high-stakes projects.

Cohn also shares advice on sizing buffers (use a percentage of the work, like 50%) and reminds us: only add buffers where they truly matter. If a team can start working with a partial deliverable, or if they have other stories to work on while waiting, a buffer might not be needed.

Why this feels like “so much work”

Cohn acknowledges that this kind of planning sounds heavy for Agile. But he’s clear: you don’t need this if you’re working with just one team—or even a few small ones with low interdependencies.

It’s only when you scale up that the cost of coordination goes up, and these techniques become your safety net.

This chapter is a masterclass in Agile at scale. To manage multiple teams successfully:

• Establish a shared estimation baseline
• Prepare stories earlier when needed
• Use a rolling lookahead plan to manage cross-team work
• Add feeding buffers when the risk of delay is high

It’s not about rigid control—it’s about smart coordination. These techniques help large Agile projects stay lean, adaptive, and aligned, even in complex environments.

Chapter 19 – Monitoring the Release Plan

In this chapter, Mike Cohn explores how Agile teams can track progress toward a release, adjust course along the way, and deal with the unavoidable uncertainty that comes with building complex products.

He compares this to navigating a ship—it’s rarely a straight journey. Just like old sailors using “dead reckoning” to guess their position based on wind and current, software teams must constantly monitor where they are in the development journey, how fast they’re going, and how much work is left.

Tracking the release: it’s more than just velocity

When a release starts, there’s usually a plan: say, eight iterations to deliver 240 story points. But the reality is always messier. New work is added, estimates change, and discoveries happen.

So progress needs to be measured not just by velocity (how many story points are done) but also by changes in scope and revised estimates.

Cohn compares this to the forces of the sea and wind pushing a boat off course. Similarly, added requirements (like wind) and new estimates (like drift) affect whether the team is actually on track—even if the original plan still “looks right” on paper. This makes transparent, visual tracking tools essential.

Velocity: what counts and what doesn’t

Cohn reinforces a core Agile rule: only count completed stories in velocity. “Complete” doesn’t mean “coded but not tested,” or “done except for edge cases.” It means fully done—coded, tested, checked in, clean, and compliant with standards.

Counting partial work leads to all sorts of trouble.

First, it’s hard to measure.

Second, it weakens trust between developers and stakeholders.

Third—and most critically—it leads to a buildup of work-in-process, which slows learning, feedback, and delivery.

If a team consistently has unfinished stories, it’s a sign that stories are too big and need to be split or better scoped during planning.

The release burndown chart

The traditional release burndown chart is simple: it shows the total work remaining across iterations. For example, if a 240-point release is planned over 8 iterations, the chart shows how many points are left at the start of each iteration.

But this chart also shows scope changes—if more points are added or estimates increase, the line goes up instead of down.

Cohn emphasizes the importance of net progress: how much work has been completed after accounting for scope changes. It’s not just about how much is done—it’s about how much is left, based on the current understanding of the project.

Burndown bar chart: a more detailed picture

Cohn introduces a more advanced visual: the release burndown bar chart. It shows progress and scope changes separately.

Each bar represents total work at the start of an iteration:

• The top of the bar moves down as work is completed.
• The bottom of the bar drops when scope is added.
• The bottom rises when scope is removed.
• Re-estimations move the top up or down.

This chart gives more insight—for instance, you can see if velocity is consistent, if scope is spiraling, or if a project is being rescued by cutting scope.

But it’s more complex and can spark debates about whether a change counts as added work or just a re-estimate.

Cohn recommends starting with the simple line chart and switching to bars only when the team is mature enough to avoid arguments.

The parking lot chart: a high-level progress snapshot

Another tool Cohn recommends is the parking lot chart. This visual groups features by themes and shows progress as a percentage of total story points completed.

It’s perfect for executive-level overviews or product stakeholders who want to see how various parts of the system are progressing. Each theme is a box labeled with:

• Number of stories
• Total story points
• Completion percentage

Boxes can even be color-coded (e.g., green for on track, red for behind) to make the state of the release easy to grasp at a glance.

This chapter pulls back the curtain on how Agile teams monitor real progress—not just based on tasks completed, but by looking at scope changes, learning, and trade-offs. Cohn makes a strong case for visualizing the release with tools like burndown charts and parking lot charts.

Most importantly, he stresses the need for honest, all-or-nothing measurement, smart story sizing, and openness to course correction. In Agile, as in sailing, knowing where you are is just as critical as knowing where you’re going.

Chapter 20 – Monitoring the Iteration Plan

In this final chapter, Mike Cohn zooms in on how teams can track daily progress during an iteration, using simple tools to stay aligned and focused.

While Chapter 19 addressed monitoring the release over months, this chapter gets into the weeds of iteration-level tracking—the day-to-day visibility that keeps Agile teams sharp.

The task board: simple, visible, effective

Cohn starts with one of the most iconic Agile tools: the task board. It’s a visual system—often a whiteboard or corkboard—where stories and their associated tasks are laid out in rows and moved across columns as work progresses.

The goal is twofold: to organize the team’s work and to give everyone a clear view of what’s going on at any moment.

The columns usually look like this:

• To Do: All planned tasks not yet started.
• Tests Ready: Indicates if acceptance criteria are defined—this ensures the team understands what “done” looks like before starting.
• In Process: Tasks currently being worked on. Each developer moves a card here when they start working on it. Cohn even suggests making this column physically narrow, so no one hoards too many tasks at once.
• To Verify: For tasks that are “done” but need a second set of eyes or testing.
• Done: Not always shown, but some teams remove cards from the board entirely once finished.
• Hours Remaining: Teams sum up the estimated hours left per story each day. These totals are used to draw the iteration burndown chart.

A key principle here is team ownership. No one is assigned tasks in advance. Developers choose what to work on when they’re ready. This allows for flow and flexibility, reducing friction and avoiding the trap of rigid, micro-managed schedules.

Task boards and bugs

Task boards are also great for dealing with legacy bugs. Cohn explains that bugs can be treated like any other work: if the product owner wants 10 high-priority bugs fixed in this sprint, the team writes 10 task cards, estimates them, and treats them like stories.

If a new urgent bug comes in mid-iteration, the team estimates it and removes an equal amount of planned work to make room. This creates balance and accountability without disrupting flow.

Iteration burndown chart

Next comes the iteration burndown chart, which is like a mini version of the release burndown. It tracks the total remaining task hours over the course of the iteration, usually updated daily. For two-week sprints or longer, this chart can show trends and early warning signs.

If hours aren’t dropping as expected, the team can investigate and adjust. Cohn recommends drawing the chart right on or next to the task board, keeping it visible and informal.

Don’t obsess over effort spent

Now, a big warning: don’t track actual hours worked. It might seem like a smart way to improve estimates, but it usually causes more harm than good.

People feel judged (evaluation apprehension), estimates become political, and collaboration suffers. Instead of learning, teams get defensive—and estimates become less accurate, not more.

Cohn backs this up with studies and a relatable example: no matter how much you practice your morning commute, there’s always natural variability. Software development is no different.

And never track individual velocity

Perhaps the strongest point in the chapter: do not track individual velocity. Agile is about teams, not individuals. Measuring individual output encourages selfish behavior, discourages collaboration, and misrepresents how real work gets done.

Most stories require multiple skill sets (UI, backend, testing), and tracking how many points one person “completes” misses the point.

Team throughput is what matters—individual velocity is not even a useful curiosity.

This chapter wraps up the book with a reminder of what makes Agile work: visibility, flexibility, and shared ownership. The task board and burndown chart are lightweight tools that keep teams in sync without bureaucracy.

What matters isn’t how many hours you worked, or who did what—it’s whether the team is moving together toward delivering real value.

Agile isn’t about micromanagement. It’s about trust, transparency, and making smart adjustments every day.

Chapter 21 – Communicating About Plans

This final chapter brings everything together by focusing on something that can make or break any plan: communication.

Mike Cohn argues that it’s not just about what we communicate, but how we do it—especially when it comes to estimates and planning.

Agile planning is dynamic, changing constantly as teams learn more, so we need communication that is frequent, honest, and two-way to keep everyone aligned and confident in the path forward.

Why communication must be frequent

Agile plans are living documents. Whether it’s a rolling lookahead or a backlog of prioritized stories, things shift often—and if that information doesn’t flow freely, it creates disconnects. On a day-to-day level, developers rely on updated burndown charts to adjust and meet iteration goals.

On a longer timeline, stakeholders need to understand where the release plan stands, what’s changed, and why. Without frequent communication, opportunities to improve and align are lost.

Honest and two-way communication builds trust

Cohn emphasizes honesty as non-negotiable. He shares an example of a team that was deliberately overpromised by executives, hoping to get 80% of what they asked for.

But that kind of game-playing erodes trust fast. When people feel they can’t speak the truth—whether it’s about slipping timelines or unrealistic expectations—they stop sharing at all.

Agile thrives on safe, open environments where people feel comfortable saying, “This might take longer than we thought.”

It’s not just about transparency from the top down. Communication needs to be two-way.

Plans improve when product owners, developers, testers, and stakeholders all contribute feedback and insights. Agile planning is iterative—not just in development, but in conversation.

Make communication understandable, not just available

Cohn makes a sharp point here: being clear is more important than being thorough. If a project is behind schedule, don’t bury that fact on page 32 of a status report.

Make it unmistakable. This is why Agile teams often rely on big visible charts—like burndown charts or parking lot charts—displayed where everyone can see them. When the information is visual and simple, the team can act on it.

Communicating the plan without false certainty

When asked when a project will finish, don’t respond with misleading precision like, “June 14, seven iterations from now.” That gives a false sense of certainty. Instead, communicate in ranges and probabilities, such as:

• “We’re 90% confident we’ll finish by July 31.”
• “Based on current velocity, we estimate 3–4 months.”

Cohn even shares a sample script from Ron Jeffries that makes this idea tangible: give the current estimate, explain how the team will deliver and adapt, and clarify that success depends on collaboration and evolving satisfaction—not rigid dates. It’s a brilliant example of honest, human communication in Agile.

Gantt charts can be useful—if used right

Though Agile is often seen as anti-Gantt, Cohn defends their use when applied appropriately. He suggests using Gantt charts to show feature-level allocation per iteration, not detailed task breakdowns.

Don’t assign individual names to features—just show which team is responsible.

And always show features spanning the full iteration, even if they finish earlier, because they’re not delivered mid-iteration.

Communicating progress with a velocity range

Cohn reinforces an idea from Chapter 19: velocity isn’t a single number—it’s a range. If a team has recently completed 19 points per sprint, but their 8-iteration average is 17, and their worst three average is 14, then all three should be used when forecasting.

This avoids overconfidence and gives a more realistic window of possibilities, helping the product owner make smarter decisions.

The end-of-iteration summary

Cohn wraps up with a practical idea: write a quick iteration summary. Even in Agile, managers often want documentation. His version is light and quick—just 15 minutes per week—and includes:

• Dates and attendance
• Build and test results
• Velocity and burndown
• Completed stories and outcomes
• Action items and review insights

This keeps a historical record and helps share learning across the team and stakeholders without heavy bureaucracy.

This chapter is a final reminder that communication is the glue that holds Agile planning together. Plans will change. Estimates will be wrong.

That’s expected. What matters is whether the team communicates openly, frequently, and clearly—so that they can adjust, improve, and deliver real value together. Agile isn’t about knowing everything upfront. It’s about learning as you go—and sharing what you learn, honestly and often.

Chapter 22 – Why Agile Planning Works

This final chapter wraps up the entire book by reflecting on why Agile estimating and planning actually work.

After going through all the tools, techniques, and mindsets presented so far, Mike Cohn steps back to show how they come together into a planning approach that is flexible, honest, and deeply aligned with how real teams work.

He frames Agile planning as a process of navigating an ever-changing solution space—balancing features, time, and people.

Frequent replanning turns anxiety into adaptability

One of Agile’s biggest strengths is that plans are revisited often, especially at the start of each new iteration. This removes the pressure of trying to create a “perfect” plan from the start, which Cohn reminds us is impossible anyway.

Early plans may be vague (“300–400 points in Q3”), but they become more precise over time (“380–400 in September”).

The key is that useful plans evolve—and the ability to constantly refine them helps the team stay grounded in reality.

Estimates of size and duration are kept separate

Agile planning succeeds, Cohn says, because it clearly separates how big something is from how long it will take. Teams first estimate the size of a story (in points), then use velocity to translate that into a timeline.

This avoids common traps like underestimating effort just to make schedules look good. He uses a fun analogy: If I ask how long it will take you to read a book, you’ll first estimate how many pages there are. Size first, duration second. That mindset keeps planning grounded.

Plans are layered across different levels

Agile supports planning at multiple time horizons—daily, iteration, and release. Each level is designed with a different level of precision and purpose:

• Daily plans are specific commitments to complete or make progress on tasks.
• Iteration plans are commitments to deliver features (with some uncertainty in task-level details).
• Release plans are strategic forecasts with the lowest precision but the highest directional value.

This layered approach helps teams stay agile in the moment while keeping sight of long-term goals.

Plans are based on features, not tasks

Instead of starting with tasks like “write code” or “create test plan,” Agile starts with user-facing features. This helps the team focus on what really matters: delivering value.

Planning by features also prevents generic plans that look the same across projects. Every Agile plan becomes a unique reflection of the product and its users.

Smaller stories keep everything flowing

From queuing theory, we know that shorter, consistent work items reduce variability and help cycle time. Cohn emphasizes breaking large stories into smaller, similarly sized ones as they approach implementation.

This supports better flow, faster delivery, and more accurate estimates—because teams are best at estimating stories within one order of magnitude (e.g., 2–8 points).

Work in progress is reset every iteration

Unlike traditional projects where half-finished work piles up, Agile resets WIP every sprint. If a story isn’t finished, it doesn’t automatically carry over—it must be re-planned.

This habit reduces cycle time, encourages focus, and supports short feedback loops, leading to smarter, faster decisions.

Progress is tracked at the team level

Instead of tracking individuals, Agile measures team progress. This avoids harmful behaviors like sandbagging or hiding problems.

People feel safer, collaboration improves, and the team can focus on outcomes, not individual performance.

Uncertainty is embraced—not feared

Cohn explains how Agile actively plans for uncertainty, both in what is being built (end uncertainty) and how it’s built (means uncertainty).

Agile doesn’t pretend everything is known upfront. It expects change. Teams reduce this uncertainty through feedback, experimentation, and adapting plans as they learn.

A dozen practical guidelines

Cohn closes with twelve concrete takeaways for successful Agile planning:

1. Involve the whole team in planning and estimating.
2. Plan at multiple levels—release, iteration, daily.
3. Keep size and duration estimates separate using distinct units.
4. Express uncertainty in scope or dates—never overpromise.
5. Replan frequently to keep targeting the right value.
6. Use visual tools to communicate progress clearly.
7. Factor learning into the plan—new knowledge reshapes everything.
8. Size stories appropriately—small for near-term, large for long-term.
9. Prioritize based on value, learning, and risk reduction.
10. Base plans on real data when possible.
11. Leave slack—don’t plan every minute of everyone’s time.
12. Coordinate multi-team work with lookahead planning.

Agile planning works because it reflects reality. It welcomes change, respects uncertainty, values collaboration, and focuses on outcomes over outputs.

By planning in layers, separating size from time, and revisiting plans regularly, teams don’t just build better software—they make better decisions.

Agile doesn’t promise guarantees. But it gives teams the best tools to discover the optimal path forward—together, one iteration at a time.

Chapter 23 – A Case Study: Bomb Shelter Studios

Setting the Scene

This chapter tells a story—literally. It follows Frank, a product manager at Bomb Shelter Studios, and his team as they shift from traditional project approaches to Agile while working on a new game called Havannah.

The team had just wrapped up their previous game, Deep Black & White, which had breakthroughs in AI but also came with a painful six-month delay and usability issues. Those problems push the team to try something new: Agile.

Introducing Agile with a Real Team

As the team gathers on a Monday morning, we’re introduced to the core characters and their roles. Frank returns from a successful conference, optimistic about the company’s future but realistic about the need to improve their development process.

Sasha, the lead architect, brings in Carlos, an Agile coach, who immediately insists that everyone be in the room—even the artist, Rose—because Agile thrives on team-wide collaboration.

Understanding the Product Through Stories

Rather than starting with a heavy spec document, the team jumps into user stories. Carlos introduces the format: “As a <user type>, I want to <goal> so that <reason>.”

The team starts brainstorming features and needs, not through a spreadsheet but by writing them down on physical index cards. Why? It fosters interaction, visibility, and a sense of collaboration.

Frank, initially skeptical, sees the value quickly. The team organizes stories by phases—before, during, and after gameplay. They come up with a surprisingly rich list, from basic features like starting a new game to nuanced ones like hint systems, AI difficulty levels, aesthetic customizations, and even winning animations.

Estimating Work with Story Points

Carlos introduces story points, a relative measure of effort and complexity—not exact hours. Through “planning poker,” the team estimates the effort for each story by choosing cards with values like 1, 2, 3, 5, 8, and so on.

If estimates differ, they talk it out until they reach agreement. This brings clarity to what’s hard and what’s not, and builds shared understanding.

For example, programming a “weak AI engine that recognizes rings” is estimated at 8 story points, while a “strong AI engine” reaches 20. Realizing it’s too big, they break it down into smaller, more manageable stories. The discussion also explores how dependencies (like needing a move engine before providing hints) can be addressed with placeholder logic or dummy implementations—another Agile principle in action.

Getting to the First Iteration Plan

The team moves to iteration planning. They commit to three stories for their first two-week sprint: implementing a weak AI for rings, enabling human-vs-human gameplay, and starting work on the AI for bridges. They break each story into smaller tasks and estimate them in hours.

This allows them to plan realistically based on team availability, personal vacations, and skills.

Prasad, the tester, feels stretched, but others offer to help. This cross-functional teamwork—where everyone pitches in to get the full story done—is a key Agile idea.

And rather than assigning tasks to individuals upfront, they focus on team commitment to delivering complete stories.

Prioritizing with Customer Research

Meanwhile, Delaney, the analyst, conducts product research using a structured questionnaire. She applies a model that classifies features into “mandatory,” “linear,” and “exciters.”

For instance, undo/redo is mandatory—users expect it. A beautiful interface is a linear feature—the better it looks, the more users like it. An interactive tutorial? That’s an “exciter”—not expected but delightful if it’s there.

This helps the team decide what to build first, what’s nice to have, and what could make their game stand out.

This chapter beautifully brings Agile to life through storytelling. Instead of abstract theory, it shows Agile in action: collaborative planning, story writing, estimation, iterative delivery, and customer validation.

It tackles common questions—How do we estimate? What’s too big? How do we plan dependencies?—through real conversations.

More importantly, it shows the mindset shift: from documentation-first to conversation-first, from role silos to team commitment, and from rigid planning to adaptive, customer-driven development.

This is Agile as it was meant to be—lightweight, collaborative, and human.

4 Key Ideas from Agile Estimating and Planning

6 Main Lessons from Agile Estimating and Planning

My Book Highlights & Quotes

The best way of dealing with uncertainty is to iterate. To reduce uncertainty about what the product should be, work in short iterations, and show (or, ideally, give) working software to users every few weeks

A good plan is one that stakeholders find sufficiently reliable that they can use as the basis for making decisions

A key tenet of agile estimating and planning is that we estimate size but derive duration

Agile teams value individuals and interactions over processes and tools because they know that a well-functioning team of great individuals with mediocre tools will always outperform a dysfunctional team of mediocre individuals with great tools and processes

Whether it is changing careers or changing the world, an idea without a network will probably never become reality

We frequently fail to acknowledge and plan for this new knowledge. Failing to plan to acquire new knowledge leads to plans built on the assumption that we know everything necessary to create an accurate plan

The beauty of this is that estimating in story points completely separates the estimation of effort from the estimation of duration

For the product owner to have the most flexibility in prioritizing, features must be written so as to minimize the technical dependencies among them

Don’t split a large story into tasks. Instead, try to find a way to fire a tracer bullet through the story

Avoid making things worse by adding related changes to an appropriately sized feature unless the related changes are of equivalent priority

If you tie iterations to the ends of months, one out of every three iterations will coincide with the end of a fiscal quarter

Because the estimate for each feature is made relative to the estimates for other features, it does not matter if our estimates are correct, a little incorrect, or a lot incorrect. What matters is that they are consistent

Conclusion

Agile Estimating and Planning is an essential guide for any project team looking to improve their process for estimation and planning. 

With detailed instructions and plenty of examples, Mike Cohn provides a comprehensive set of tools and techniques that can be quickly implemented to make any project successful. 

By understanding the basics of Agile Estimating and Planning book, and applying the best practices outlined in the book, teams can quickly improve their processes and reach their goals.

I am incredibly grateful that you have taken the time to read this post.

Support my work by sharing my content with your network using the sharing buttons below.

Want to show your support and appreciation tangibly?

Creating these posts takes time, effort, and lots of coffee—but it’s totally worth it!

If you’d like to show some support and help keep me stay energized for the next one, buying me a virtual coffee is a simple (and friendly!) way to do it.

Do you want to get new content in your Email?

Do you want to explore more?

Check my main categories of content below:

• Book Notes
• Career Development
• Essays
• Explaining
• Leadership
• Lean and Agile
• Management
• Personal Development
• Project Management
• Reading Insights
• Technology

Navigate between the many topics covered in this website:

Agile Agile Coaching Agile Transformation Art Artificial Intelligence Blockchain Books Business Business Tales C-Suite Career Coaching Communication Creativity Culture Cybersecurity Decision Making Design DevOps Digital Transformation Economy Emotional Intelligence ESG Feedback Finance Flow Focus Gaming Generative AI Goals GPT Habits Harvard Health History Innovation Kanban Large Language Models Leadership Lean Learning LeSS Machine Learning Magazine Management Marketing McKinsey Mentorship Metaverse Metrics Mindset Minimalism MIT Motivation Negotiation Networking Neuroscience NFT Ownership Paper Parenting Planning PMBOK PMI PMO Politics Portfolio Management Productivity Products Program Management Project Management Readings Remote Work Risk Management Routines Scrum Self-Improvement Self-Management Sleep Social Media Startups Strategy Team Building Technology Time Management Volunteering Web3 Work

Do you want to check previous Book Notes? Check these from the last couple of weeks:

• Book Notes #127: The Laws of Simplicity by John Maeda2025-04-04
• Book Notes #126: Inevitable by Mike Colias2025-03-24
• Book Notes #125: Revenge of the Tipping Point by Malcolm Gladwell2025-03-21
• Book Notes #124: Radical Candor by Kim Scott2024-09-04
• Book Notes #123: The Personal MBA by Josh Kaufman2024-05-09

Support my work by sharing my content with your network using the sharing buttons below.

Want to show your support tangibly? A virtual coffee is a small but nice way to show your appreciation and give me the extra energy to keep crafting valuable content! Pay me a coffee: