How to Get a Job For Project Managers

Learn how to write resume and interview

Leadership for Project Managers

Learn how to lead and drive project success.

Project Management with AI

From a beginner to project management professional.

Agile Project Management and SCRUM with AI

Learn to run Scrum and Agile with AI.

Estimation Methods

Estimation Methods are collaborative techniques used by the Scrum Team to size user stories and estimate task effort for planning and forecasting. In SBOK, these include tools like Planning Poker, Wideband Delphi, Affinity Estimation, T-shirt sizing, and Ideal Time, focused on relative sizing and team consensus. They support Product Backlog ordering and help forecast releases and sprints using empirical velocity.

Key Points

  • Used during Estimate User Stories, Estimate Tasks, Backlog Refinement, and Sprint Planning.
  • Relies on team consensus, relative sizing, and comparison to reference stories.
  • Common techniques include Planning Poker, Wideband Delphi, Affinity Estimation, T-shirt sizing, and Ideal Time.
  • Produces estimated user stories (story points or T-shirt sizes) and task effort (ideal hours) for sprint planning.
  • Supports Product Owner in prioritization by balancing value, risk, and size.
  • Scrum Master facilitates to reduce bias, ensure time-boxing, and maintain transparency.

Purpose of Analysis

Estimation in Scrum helps the team understand the relative size and complexity of work so they can plan sprints, forecast releases, and manage risk. It informs Product Backlog ordering by giving the Product Owner a realistic view of effort versus value. It also enables empirical planning by connecting story points to observed velocity.

Method Steps

  1. Prepare: Select a set of refined user stories with clear acceptance criteria; confirm Definition of Done and estimation scale (story points or T-shirt sizes).
  2. Choose a technique: Planning Poker, Affinity Estimation, T-shirt sizing, Wideband Delphi, or a mix (e.g., T-shirt sizing first, then Planning Poker for borderline items).
  3. Discuss and clarify: Product Owner answers questions; the team identifies assumptions, risks, and dependencies.
  4. Estimate: Individuals propose sizes privately (e.g., simultaneous card reveal) or group items by similarity (affinity), then converge to consensus.
  5. Triangulate: Compare to reference stories and adjust to maintain consistency across the backlog.
  6. Record and split: Document final estimates, note assumptions, and split any story that exceeds the team’s sizing threshold.
  7. Task-level estimation (optional, near Sprint Planning): Break selected stories into tasks and estimate ideal hours to check capacity.

Inputs Needed

  • Refined user stories and acceptance criteria.
  • Reference stories with agreed point values or size categories.
  • Team capacity and historical velocity (if available).
  • Definition of Done, known risks, and dependencies.
  • Product vision, release goals, and constraints that influence prioritization.

Outputs Produced

  • Estimated user stories in story points or T-shirt sizes.
  • Consensus notes and key assumptions for future reference.
  • Updated Product Backlog ordering by the Product Owner based on value versus size.
  • Task-level effort estimates in ideal hours for sprint planning (when used).
  • Improved velocity forecast and release planning baselines.

Interpretation Tips

  • Treat story points as relative size, not as hours or days.
  • Use triangulation with reference stories to keep consistency across sprints.
  • Expect higher uncertainty early; refine estimates as stories mature.
  • Use team velocity empirically to forecast, not to set targets.
  • Re-estimate only when a story’s scope or understanding changes materially.

Example

During refinement, the team estimates a new search feature. Using Planning Poker, members reveal 5 and 8 points. They discuss that integration and performance tests add complexity, then compare it to a known 5-point reference.

They agree on 8 points, capture the assumption that a third-party API is stable, and the Product Owner reorders the backlog, moving a smaller but high-value story ahead for the next sprint. Before Sprint Planning, the team breaks the selected stories into tasks and estimates ideal hours to confirm capacity.

Pitfalls

  • Anchoring on the first number or deferring to the loudest voice instead of reaching true consensus.
  • Treating story points as commitments or as direct time conversions.
  • Overprecision for vague epics instead of splitting and refining first.
  • Gaming velocity by inflating points to meet targets.
  • Estimating without cross-functional team members who will do the work.

PMP/SCRUM Example Question

During Backlog Refinement, the team sees wide variation in initial sizes for a complex user story. The Scrum Master wants to reduce anchoring and quickly reach a consensus estimate. Which technique is MOST appropriate?

  1. Round-robin updates where each member states an estimate aloud in turn.
  2. Planning Poker with simultaneous reveal and discussion rounds.
  3. The Product Owner selects the estimate based on business priority.
  4. Use last sprint’s velocity as the estimate for the story.

Correct Answer: B — Planning Poker with simultaneous reveal and discussion rounds.

Explanation: Planning Poker reduces anchoring by private selection and simultaneous reveal, then drives consensus through discussion. The other options either introduce bias, misuse velocity, or bypass team estimation.

AI Systems with Claude, for Scrum Masters and Project Managers

Most AI pilots in project management do not fail on the model. They fail because somebody pointed the thing at a decision instead of at a task. This course is built around that distinction, and around the work that follows once you get it right.

Eight teaching sections, taught against one running project from the first lecture to the last. You watch a system get built, then you build the same one against your own sprint. Nothing here is a demo that works only on the example.

You finish with five working systems and you keep them. The sprint report machine turns your board export and standup notes into the report you currently write by hand. The retro intelligence system tells you what the team keeps saying, not just what it said this time. The stakeholder comms engine drafts the update in the register the audience expects. The backlog health monitor flags the quiet decay nobody has time to check for. The risk and dependency tracker follows the chains that actually bite.

Seventy-six working files ship with it, across four sections, so every system is built against real sprint data rather than material invented for a slide. Four sprints of retrospectives, board exports, standup notes, backlog and risk data.

Explore the Course


Launch your Agile career!

HK School of Management helps you learn Agile and Scrum with practical playbooks, AI-powered prompts, and real-world workflows for planning and delivery. Practical skills, tools, and guidance you can apply right away. Covered by Udemy's 30-day refund policy.

Learn More