Agile in plain language
Agile is a way of organizing product development around short feedback loops. Instead of attempting to specify and schedule an entire product upfront, a team delivers in smaller increments, learns from real results, and adjusts what it does next.
That does not mean “working without a plan.” It means treating a plan as something that should improve as the team learns. Healthy agile teams make work visible, limit how much is in progress, check outcomes frequently, and collaborate closely with the people affected by the product.
The principles that matter here
- Shared understanding: the team needs a common picture of the problem before it can make a useful forecast.
- Small feedback loops: estimates and plans are revisited as new information arrives.
- Team ownership: the people doing the work participate in understanding and estimating it.
- Adaptability: an estimate is a current best judgment, not a promise carved in stone.
How Scrum fits
Scrum is one framework teams can use to put agile ideas into practice. Work is organized into a Product Backlog and selected for a timeboxed Sprint. The team inspects progress daily, reviews the resulting increment with stakeholders, and reflects on its process in a retrospective.
Backlog refinement and estimation support that cycle, although story pointing itself is not a required Scrum event. Teams often point upcoming work during refinement so they can discuss uncertainty before Sprint Planning. Other agile teams—including those using Kanban or a hybrid workflow—can use the same technique whenever relative estimates help them plan.
You do not need to “do Scrum” to benefit from independent estimates and a focused discussion of the differences.
What story points actually measure
A story point is a relative estimate of a work item's overall size. Teams usually consider a mixture of effort, complexity, uncertainty, and risk. A five-point item should feel meaningfully larger than a two-point item to that team, but five points is not intended to mean five hours or five days.
Relative sizing is useful because people are often better at comparing work than forecasting an exact duration. The team can ask, “Is this about the same size as our reference three, or is there enough uncertainty to make it an eight?” That comparison creates a useful boundary for discussion.
A point value is the result of shared understanding—not a substitute for it.
Why the numbers spread out
Many teams use a modified Fibonacci sequence such as 1, 2, 3, 5, 8, and 13. The gaps grow because confidence generally decreases as work gets larger. A wide range discourages false precision and makes it easier to say that an item should be split or investigated before the team commits to it.
The question-mark value is equally useful. It signals that a participant does not yet understand the item well enough to estimate it—a prompt for clarification, not a failure to participate.
Why independent estimation works
In an unstructured estimation conversation, the first confident number can anchor the room. People may adjust toward it even when their own experience points elsewhere. Seniority, personality, or simply who speaks first can shape the result.
Private story pointing changes the sequence: everyone considers the work independently, commits to a choice, and reveals at the same time. Differences become visible before the group has converged socially.
The most valuable moment is often a split vote. A developer may see an integration risk, a tester may notice unclear acceptance criteria, or a designer may know about an unresolved interaction. The disagreement is new information the team can use.
A worked estimation example
Imagine a team estimating “Add search to the customer list.” The request sounds small, but the first private vote comes back 2, 3, 3, 8. The facilitator asks the people who chose 2 and 8 what each assumed.
The 2 assumes a text filter over customers already loaded in the browser. The 8 assumes search must work across every customer in a large account, including records that have not loaded yet. Both estimates are reasonable for different versions of the task. Averaging the votes would hide that difference.
- Clarify the behavior: the product owner confirms that search must cover the full account and match names even when the list is paginated.
- Surface the unknown: the team checks whether the existing API supports server-side search and whether partial matches are required.
- Choose a next step: if the API behavior is known, update the acceptance criteria and vote again. If it is unknown, create a short investigation task before sizing the implementation.
The useful result is a clearer piece of work and an explicit decision. A second vote can now reflect the same scope for everyone.
How to run a useful pointing session
- Prepare estimate-ready items. Make the desired outcome and acceptance boundaries clear enough to discuss.
- Include the people who understand the work. Cross-functional perspectives improve the estimate and expose hidden dependencies.
- Name a facilitator. The moderator keeps the session moving but should not steer the vote.
- Keep choices private until reveal. Simultaneous reveal protects independent judgment.
- Ask about the edges. Invite a high and low estimator to explain what they saw. Focus on assumptions, not on defending a number.
- Timebox the discussion. If uncertainty cannot be resolved, create a research task, split the work, or use “?” rather than forcing agreement.
- Record the team's decision. Put the chosen estimate in the system where the team manages its backlog.
“What did you include that others might have left out?” “Which part is uncertain?” “What would make this item smaller?” “Can we agree on the expected outcome before voting again?”
Common pitfalls to avoid
Converting points directly into hours
This reintroduces the precision that relative estimation is designed to avoid. Use points to compare work within the team, and use observed delivery history for forecasting.
Comparing teams by velocity
Point scales are local. One team's five may be another team's three. Turning velocity into a performance target encourages inflation and makes the measure less useful.
Averaging away important differences
An average summarizes votes, but it does not resolve them. A 2–13 split contains information that a displayed average cannot explain. Discuss the spread first.
Pointing work that is too vague
If most of the room cannot explain the intended outcome, the item needs clarification or discovery—not a more determined estimate.
What happens after the reveal?
The team may agree immediately, revote after discussion, split the item, or defer it while someone investigates an unknown. All are valid outcomes. The goal is not unanimity at any cost; it is enough shared understanding to make a responsible planning decision.
Story Pointing Hub keeps the mechanics simple so the conversation gets the attention. Create a free room—no account required.