Frequently Asked Questions about story points and planning poker.
Story Points
FAQ
Find answers to questions about story points and planning poker.
Story points as a concept emerged within the Agile community, particularly in the context of Extreme Programming (XP) and Scrum. Ron Jeffries, one of the creators of XP, is credited with early discussions on relative estimation, which led to story points as a unit of measure for effort. Mike Cohn popularized story points as part of his teachings on Agile practices, explaining their purpose and implementation in his books and blogs.
Story points represent a relative estimate of effort required to complete a backlog item, considering factors like complexity, risk, and the amount of work involved. Rather than attempting to estimate the exact time or effort required for each task, the team considers how difficult or complex each task is in relation to others. For example, if a task is deemed twice as difficult as another, it might be assigned twice as many points.
Story points encourage abstract thinking and avoid the pitfalls of equating effort to specific durations. Relative estimation fits the way the human brain handles uncertainty and complex decision-making. The brain is better at estimating comparative relationships than exact amounts. Cognitive psychology studies suggest that people are generally more reliable at recognizing patterns or differences in magnitude than in providing precise numbers (Tversky & Kahneman, Judgment Under Uncertainty: Heuristics and Biases).
Estimating with story points often involves a collaborative process like planning poker. In planning poker, team members individually assign story points to a task using cards, ensuring everyone’s perspective is heard. After revealing their estimates simultaneously, the team discusses any significant differences. This fosters shared understanding and uncovers complexities or assumptions that might not be obvious. The process continues until the team reaches a consensus on the estimate. This method ensures diverse input, promotes alignment, and reduces bias, leading to more accurate and well-rounded story point estimations for sprint planning and prioritization.
Story points can positively impact team performance by providing a clear, shared understanding of the effort required for tasks, which helps in planning and prioritization. By estimating tasks relative to one another, teams can better gauge their capacity, set realistic sprint goals, and track progress over time through velocity (the number of story points completed per sprint). This improves predictability and helps manage expectations. However, if used improperly, such as overemphasizing velocity, story points can lead to rushed work or burnout. When used effectively, story points support better communication, collaboration, and continuous improvement in team productivity.
No, story points are specific to each team. What one team considers a 5-point story might be a 3-point story for another because the baseline differs from team to team. As a result, velocity comparisons across teams are not meaningful. Instead, story points and velocity are most valuable for helping a specific team track its own progress, improve planning, and forecast work within its context.
Story points and planning poker are closely connected, as planning poker is a common technique for estimating story points. In planning poker, team members use a predefined scale, often Fibonacci numbers, to assign story points to a task based on its complexity, effort, and uncertainty. Each person independently selects a card representing their estimate, and all cards are revealed simultaneously. Discrepancies prompt discussion to align understanding of the task. This process ensures diverse perspectives, encourages collaboration, and leads to a consensus on the story point value. Planning poker helps make story point estimation structured, transparent, and inclusive.
Story points and velocity are closely related in Agile project management. Story points measure the relative effort, complexity, and uncertainty of tasks, while velocity represents the total number of story points a team completes in a sprint. Velocity is a key metric used to assess a team’s capacity and predict how much work they can accomplish in future sprints. By tracking velocity over time, teams gain insight into their performance and can make informed decisions about sprint planning and project timelines. However, velocity should be used as a guide, not a target, to avoid sacrificing quality for higher point totals.
Yes, story points can be used in non-software projects to estimate and plan work. They are particularly useful in any project involving tasks of varying complexity, effort, and uncertainty. For example, in marketing campaigns, story points can measure the effort required for tasks like content creation, event planning, or social media management. In construction or research projects, they can help assess relative workload for design phases, data collection, or analysis. The key is adapting story points to the specific context and ensuring the team understands their use as a measure of relative effort rather than precise time. This fosters better planning and collaboration.
Overemphasis on Velocity is a common pitfall where teams become overly focused on increasing the number of story points they complete each sprint, rather than on the value or quality of the work. Teams may rush to complete tasks or inflate story point estimates to appear more productive, compromising quality and leading to technical debt. The focus might shift from delivering valuable features to simply hitting higher velocity numbers, which can result in completing low-impact tasks instead of meaningful work. This mindset can also cause burnout, as teams push to meet targets without considering sustainable workloads. Velocity should be used as a guide to understand capacity and improve estimation accuracy, not as a goal in itself. The focus should remain on delivering value and maintaining quality.
Alternatives to story points for relative estimation include methods like T-shirt sizing, where tasks are categorized as Small, Medium, or Large based on effort; Affinity estimation, where tasks are grouped by relative size through team discussion; and the Bucket system, which organizes tasks into predefined complexity buckets. Ideal time estimation uses hours or days to estimate effort but can be less accurate due to real-world interruptions. Kanban-style estimation focuses on task size relative to others in a continuous delivery system. These methods allow teams to estimate tasks relative to one another, supporting sprint planning and prioritization without story points.
Get Started
Create a planing poker room at get started estimating with your team right away