Exam objective 3.3 of the CAPM syllabus demands that you understand how agile teams estimate work and plan short cycles of delivery. Without solid estimation and planning, projects run over budget, miss deadlines, and frustrate customers. This chapter breaks down the core techniques — story points, velocity, planning poker, and iteration planning — so you can answer exam questions with confidence and see how real teams stay on track.
Jump to a section
A simple way to picture Agile Estimation and Planning
A shared kitchen in a busy restaurant is the scene of constant, coordinated activity. Each station — the grill, the prep table, the pastry section — has its own tasks and tools. The head chef does not plan the entire week's menu in perfect detail on Monday morning, because the daily catch, the seasonal produce, and the sudden reservations would make that plan useless by Tuesday. Instead, the team works in short cycles called "sprints."
At the start of each sprint, the chef and the cooks gather for a planning session. They look at the backlog of menu items — the handwritten list of dishes customers have requested or that need to be refined. The cooks pick the most important few items they believe they can finish in the next two days. They do not estimate in hours; they estimate using a relative scale. A simple dish like grilled asparagus is a "1" in effort, while a complex five-course tasting menu might be a "13." These numbers are story points, a measure of relative effort, not time. The team's historical speed — how many story points they complete per sprint — is their velocity. When a new dish comes in, the team plays "planning poker": each cook privately holds up a card with their estimate, and they discuss differences until they agree. This prevents one person's optimism from overriding the group's collective experience. Just as a kitchen adapts to a surprise VIP table without throwing out the whole week's plan, agile teams use iteration planning to adjust their work every short cycle, delivering value steadily rather than all at once."
Traditional project estimation often tries to predict every task in hours or days, months before the work begins. That approach fails in software and IT projects because requirements change, problems appear unexpectedly, and people discover new things as they build. Agile estimation and planning offer a different philosophy: accept uncertainty, work in small batches, and learn as you go.
Let us define the key terms from the ground up.
Story points are a unit of measure for the effort required to implement a user story. A user story is a short, simple description of a feature told from the perspective of the user who wants it. For example: "As a customer, I want to reset my password so I can regain access to my account." Instead of saying this will take four hours, the team assigns it a story point value based on three factors: the amount of work, the complexity of the work, and any risk or uncertainty involved. The team chooses a baseline story — say, a straightforward task like "change the colour of a button" — and calls that 1 story point. Every other story is then compared to that baseline. A password reset feature might be 3 story points because it involves email logic, security checks, and a database update. The entire set of user stories waiting to be worked on is called the product backlog.
Velocity is the number of story points a team completes in one iteration (often called a sprint, a fixed timebox of one to four weeks). If your team completes 20 story points in a two-week sprint, your velocity is 20. Velocity is measured from historical data, not guessed. Over several sprints, the team's velocity becomes more predictable. This allows the product owner (the person who decides what to build next) to forecast how many story points the team can deliver in a release. A common exam trap is thinking velocity is a target or a goal. It is not. Velocity is a measurement of past performance used for forecasting — like knowing your car averages 30 miles per gallon, not a promise you must drive exactly that fuel efficiency.
Planning poker is a consensus-based estimation technique. The team sits together with a deck of cards numbered in a sequence like the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 100, and sometimes "?" for uncertainty or "coffee cup" for a break). The product owner reads a user story and answers questions. Each team member privately selects a card that represents their estimate in story points. Everyone reveals their card simultaneously. If all numbers are close — say, 3, 5, and 5 — the discussion is brief. If someone picks 13 while others pick 3, that person explains their reasoning. The team re-estimates. This repeats until the estimates converge. Planning poker prevents one dominant personality from influencing the whole team and surfaces hidden assumptions. For the CAPM exam, remember that planning poker is a form of "broadband Delphi" estimation and is done by the whole team, not just the project manager.
Iteration planning (or sprint planning) is the meeting where the team selects a set of user stories from the product backlog to complete in the upcoming iteration. The team uses their velocity to decide how many story points they can realistically commit to. The goal is not to pack every possible task into the sprint; it is to pick a manageable chunk that the team can deliver with high quality. The output is a sprint backlog — the subset of the product backlog that the team will work on during that sprint. The team also breaks each story into smaller tasks (often in hours) and assigns ownership.
Why does all this matter? Agile estimation replaces the illusion of precision with practical forecasting. Instead of promising a fixed date with a fixed scope, the team learns how much work they can actually complete per iteration. The product owner then prioritises the backlog based on business value. This leads to a process called "rolling wave planning": you plan the next iteration in detail, and farther-out items are kept as rough estimates. The exam will test you on the difference between relative estimation (story points) and absolute estimation (hours). It will ask who participates in planning poker (the team), and what velocity is used for (forecasting, not evaluating performance). It may present scenarios where a manager uses velocity as a stick to push the team — you must recognise that as an anti-pattern.
In short, agile estimation and planning are about making smart bets with imperfect information, adjusting every sprint, and using team-derived data to guide decisions. The CAPM will expect you to know the definitions, the sequence of events, and the roles of the product owner, scrum master, and development team in these activities.
Refine the Product Backlog
Before iteration planning, the product owner ensures the highest-priority user stories are well-defined and ordered. This is called backlog refinement or grooming. The team may review stories to add acceptance criteria or split large stories into smaller ones. This step saves time during planning.
Review Team Velocity
The scrum master shares the team's velocity from the last three to five sprints. This historical data gives a realistic starting point for how many story points the team can handle in the upcoming iteration. Velocity is calculated by summing the story points completed in each sprint and averaging them.
Conduct Planning Poker
The team estimates each user story in story points using planning poker. The product owner reads the story and answers questions. Each team member privately selects a card and everyone reveals simultaneously. The team discusses any large gaps and re-estimates if needed. This step produces a story point estimate for each story.
Select Stories for the Sprint
The team uses their velocity and the estimates to choose which stories from the top of the product backlog they can realistically complete. The total story points of selected stories should be at or slightly below the team's average velocity. The product owner may reprioritise to fit within the capacity.
Create the Sprint Backlog
The team breaks each selected user story into smaller technical tasks (e.g., "create database table", "update API endpoint", "write unit tests"). Each task is estimated in hours if needed. The sprint backlog is committed to, and the team begins the iteration. The plan is visible to the whole team.
Consider a real software company, CloudCart, that builds an e-commerce platform. The product owner maintains a backlog of user stories: "Add a wishlist feature", "Optimise checkout for mobile", "Support multi-currency pricing", and about forty more. The development team has six engineers and one scrum master. They work in two-week sprints.
The team has been together for three months. Their historical velocity is 15 story points per sprint. During iteration planning, the product owner presents the highest-priority stories from the backlog. The team discusses each story to clarify technical assumptions. For example, the "multi-currency pricing" story involves integrating a currency exchange API and updating the product database schema. The team agrees it is 8 story points. The "wishlist" feature is 5 story points. The mobile optimisation story is 3 story points. The total is 16 — one point over the team's average velocity of 15. The team decides to commit to the wishlist and mobile optimisation (8 story points total) and bring the multi-currency story into the sprint only if they finish early. They are not forced to take on 16 points.
During the sprint, the team works through their tasks. At the daily stand-up meeting, a developer reports that the wishlist feature's database query is more complex than expected. The team collectively decides to descope a non-essential animation from the wishlist to stay on track. They do not cancel the sprint; they adjust within it, which is a core agile principle.
At the end of the sprint, the team completes 12 story points — the wishlist (with reduced animation) and the mobile optimisation. Their velocity for this sprint is 12, not 15. The scrum master notes this in the retrospection. The team discusses that the wishlist database complexity was underestimated. For the next iteration, the team uses the actual 12-point velocity as their new forecasting baseline. They do not punish anyone for delivering fewer points; they learn that stories involving database changes need deeper analysis before estimation.
The product owner uses the updated velocity to tell stakeholders that the multi-currency feature (8 points) plus the remaining backlog items will take roughly three more sprints at 12 points each. This is a forecast, not a promise. The real world example shows why velocity fluctuates and why relative estimation works better than hour-based guessing. IT professionals use these techniques every sprint to plan, adapt, and communicate progress without over-committing.
Typical tools used in practice: - Physical or digital planning poker cards (apps like Planning Poker Online) - Project tracking software (Jira, Trello, Asana) to manage backlog and story points - Burndown charts that plot remaining story points against sprint days to visualise progress - Spreadsheets for calculating velocity from historical sprint data
The CAPM exam tests your knowledge of agile estimation and planning through scenario-based questions and definition recall. The exam expects you to distinguish between traditional (waterfall) estimation and agile estimation. Here is what you must absolutely know.
Key concepts that appear repeatedly: - The definition of story points as a relative measure of effort, complexity, and risk — NOT time. - The formula and purpose of velocity (story points completed per iteration, used for forecasting). - Planning poker as a consensus-based technique that involves the full development team, not just the project manager. - The output of iteration planning: the sprint backlog. - The sequence: product owner prioritises backlog -> team selects stories based on velocity -> team breaks stories into tasks -> sprint begins.
Common traps the exam sets: - They will give a scenario where a project manager assigns story points to tasks without the team's input. Correct answer: story points must be estimated by the team doing the work. - They will describe a manager demanding the team increase their velocity each sprint. Correct answer: velocity is a measurement, not a performance target. Forcing velocity targets leads to inflated estimates or poor quality. - They will pretend that story points equal hours. A question might state: "Team A estimated 5 story points = 10 hours. Team B estimated 5 story points = 20 hours. Which team is more accurate?" Correct answer: story points are relative within a team; comparing points across teams is meaningless. Each team has its own scale. - They will ask who can estimate during planning poker. The options might include the product owner or the scrum master. The correct answer is the development team. The product owner provides clarification on the story but does not estimate. The scrum master facilitates but does not typically estimate unless they are also on the development team.
Exam questions often require you to choose the best action in a given situation: - Example: "During sprint planning, the team realises their capacity is lower than the backlog priority items. What should the product owner do?" Answer: The product owner should reprioritise the backlog or remove lower-priority items so the team only commits to what they can realistically deliver. - Example: "A team's velocity has been consistent at 20 points for three sprints. In sprint four, they deliver 15 points. What is the best interpretation?" Answer: Velocity is a historical average that can fluctuate; the team should investigate the cause (e.g., complexity, holidays, blockers) but not panic.
Remember for the exam: - Estimation should be done by the people who will do the work. - Use relative sizing (story points) not absolute (hours). - Planning poker is for reaching consensus, not for competitive bidding. - Velocity is not a KPI or a target. - Iterations are timeboxed; scope is flexible within the iteration, not the duration. - The product backlog is dynamic and prioritised by the product owner.
The exam will likely include at least two questions on these topics, one on definitions and one on scenario application. Practise with sample questions to get comfortable with the language. Memorise the definitions of backlog, iteration, sprint, story point, velocity, and planning poker as they appear in the PMBOK Guide and the Agile Practice Guide.
Story points measure relative effort, complexity, and risk — never time.
Velocity is the team's historical average of completed story points per iteration, used for forecasting, not performance evaluation.
Planning poker involves the full development team estimating privately and discussing differences to reach consensus.
Iteration planning produces the sprint backlog: the subset of the product backlog the team commits to deliver in the next sprint.
The product owner prioritises the backlog; the team decides how much work to take on based on velocity.
Estimates are best done by the people who will perform the work, not by managers or external experts.
These come up on the exam all the time. Here's how to tell them apart.
Story Points
Relative measure of effort, complexity, and risk
Used for estimation within a team
Cannot be compared across teams
Hours
Absolute measure of time
Used for estimation in traditional projects
Comparable across teams but often inaccurate
Velocity
Historical measure of completed story points per sprint
Used for forecasting future work
Derived from actual team performance
Capacity
Planned availability of team members (number of hours/person-days)
Used for resource planning
Derived from schedules and calendars
Planning Poker
Group consensus technique
Reduces bias through simultaneous revelation
Requires full team involvement
Expert Judgment (single person)
Single person provides estimate
Vulnerable to personal bias
Quick but less reliable for complex tasks
Product Owner
Prioritises the product backlog
Defines user stories and acceptance criteria
Does not estimate story points
Development Team
Estimates story points using planning poker
Selects work for each sprint
Breaks stories into tasks and does the work
Mistake
Story points are a unit of time, like hours or days. A 3-point story takes 3 hours.
Correct
Story points are a relative measure of effort, complexity, and risk. A 3-point story takes about three times the effort of a 1-point baseline story, but the actual time can vary widely.
People come from traditional project management where everything is estimated in hours, so it feels natural to equate story points with time. The CAPM exam deliberately tests this confusion.
Mistake
The project manager should assign story points to user stories because the manager has the most experience.
Correct
The development team that will do the work must estimate the story points collaboratively. The manager may facilitate but should not impose estimates.
In hierarchical organisations, managers are accustomed to making top-down decisions. Agile estimation is bottom-up and team-based. The exam often presents a scenario where a manager assigns points, and the correct answer is to involve the team.
Mistake
Velocity is a target. The team should aim to increase velocity every sprint.
Correct
Velocity is a measurement of past capacity used for forecasting future work, not a target. Pressuring teams to increase velocity leads to inflated estimates or quality shortcuts.
Many workplaces use metrics as goals (e.g., sales targets). The exam wants you to recognise velocity as a neutral measurement, not a performance indicator.
Mistake
All team members must agree on every story point estimate in planning poker, or it is a failure.
Correct
The goal is consensus, not unanimity. If estimates are close, the team can take the average or the majority. If far apart, they discuss and re-estimate. Complete agreement is not required.
People misunderstand "consensus" as requiring everyone to be 100% happy. In agile, consensus means everyone can support the decision even if it is not their first choice. This nuance appears in scenario questions.
Mistake
The product owner must attend iteration planning and estimate story points alongside the developers.
Correct
The product owner attends to clarify user stories and answer questions about business value, but they do not estimate. Only the development team estimates.
Product owners in real life often want to influence estimates to get more features into a sprint. The exam tests role boundaries: the product owner owns the 'what', the team owns the 'how' and the estimates.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
There is no universal number. Story points are unique to each team. A team's velocity is the average of their own historical data. The exam expects you to know that velocity is team-specific and cannot be compared across teams.
No. Only the development team that will do the work should estimate. The product owner provides context but does not assign points. The CAPM exam often tests this role boundary.
Indirectly, yes. By knowing your velocity, you can forecast how many sprints a given set of stories will take. The exam will ask you to calculate a release date given a backlog size and velocity, but always note that this is a forecast, not a promise.
The team should investigate the root cause: was there a holiday? A sick team member? Higher complexity than expected? Velocity naturally fluctuates. Do not use it as a stick to push the team. The exam tests that velocity is a measurement, not a performance target.
In practice, they mean the same thing: a timeboxed period (usually 1-4 weeks) during which the team completes work. The CAPM uses the term 'iteration' broadly in the context of agile methodologies.
Planning poker prevents groupthink by making everyone estimate privately before revealing. It reduces bias from dominant personalities and ensures all team members think independently first. The exam may ask about the purpose of simultaneous revelation.
You've finished Agile Estimation and Planning. Continue through the CAPM study guide to build a complete picture of the exam.
Done with this chapter?