How do I estimate issues with story points?
Master issue estimation to improve sprint planning, velocity tracking, and automated sprint capacity management.
What are story points and why use them?
Story points are a unit of measure for expressing the overall effort required to implement an issue. Unlike time-based estimates, story points account for complexity, uncertainty, and effort in a relative scale that helps teams plan more effectively.
In Zenhub, story points power several critical features including velocity tracking, sprint burndown charts, automated sprint capacity management, and team performance insights. When you consistently estimate issues, Zenhub can automatically suggest how much work your team can handle in upcoming sprints based on your historical velocity.
Story points use a relative scale where teams compare issues to each other rather than estimating absolute time. A 5-point issue should require roughly five times the effort of a 1-point issue, but the actual time may vary based on team member expertise, external dependencies, or technical complexity.
How to add story points to issues
You can estimate issues in several ways depending on your workflow preferences.
From the Work Tracker: Navigate to your workspace's Work Tracker and click on any issue card. In the issue details panel that opens on the right, you'll see an "Estimate" field. Click this field and enter your story point value, then press Enter to save. The estimate will immediately appear on the issue card for easy visibility during sprint planning.
From GitHub (with browser extension): When viewing an issue directly in GitHub, look for the Zenhub sidebar on the right side of the issue. You'll see an "Estimate" section where you can add or edit story points. This ensures your estimates are always accessible whether you're working in Zenhub or GitHub.
During issue creation: When creating new issues in Zenhub, you can add story points immediately in the issue creation form. This helps ensure estimation becomes part of your standard issue creation workflow rather than a separate step.
Bulk estimation: For multiple issues, you can select several issue cards on the Work Tracker (using Ctrl/Cmd + click) and apply estimates to multiple issues simultaneously, which speeds up backlog grooming sessions.
Planning Poker for team estimation
Planning Poker provides a collaborative way for teams to estimate issues together, reducing individual bias and improving estimate accuracy. This feature works particularly well during sprint planning or backlog refinement sessions.
To use Planning Poker, navigate to any issue in Zenhub and look for the "Planning Poker" option in the issue details. Click "Start Planning Poker" to begin a session where team members can submit their estimates privately before revealing them simultaneously.
During a Planning Poker session, each team member selects their estimate from the standard Fibonacci sequence (1, 2, 3, 5, 8, 13, 21). Once everyone has voted, all estimates are revealed at once. If there's a wide variance in estimates, team members can discuss their reasoning before voting again until the team reaches consensus.
The final agreed-upon estimate is automatically applied to the issue, ensuring everyone is aligned on the effort required. Planning Poker sessions help identify assumptions, uncover requirements that weren't initially obvious, and build shared understanding across the team.
Story point scales and best practices
Most teams use the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21) because it reflects the increasing uncertainty that comes with larger estimates. The gaps between numbers get wider as estimates get larger, acknowledging that big tasks are harder to estimate precisely.
Establishing your baseline: Start by identifying a simple, well-understood issue that represents 1 story point for your team. This becomes your reference point for all other estimates. All future estimates should be relative to this baseline issue.
Common estimation guidelines:
- 1-2 points: Small, straightforward tasks with clear requirements
- 3-5 points: Medium complexity requiring some design or research
- 8-13 points: Large features that should likely be broken down further
- 21+ points: Epics that definitely need to be split into smaller issues
Keep estimates consistent: The same type of work should receive similar estimates regardless of who's doing it. Story points measure the work itself, not the person performing it. A junior developer and senior developer should estimate the same issue identically, even though completion time will differ.
Update estimates when needed: If you discover during implementation that an issue is significantly more or less complex than originally estimated, update the story points to reflect reality. This improves future estimation accuracy and keeps your velocity data meaningful.
Integration with Zenhub reports
Story points integrate seamlessly with Zenhub's reporting suite to provide actionable insights about team performance and project progress.
Sprint Burndown charts: These charts show story point completion throughout a sprint, helping teams track whether they're on pace to complete their commitments. The ideal burndown line compares against actual progress to highlight potential delivery risks early in the sprint.
Team Velocity reports: Track your team's story point delivery over time to understand capacity trends and plan future work more accurately. Velocity data helps with release planning and setting realistic stakeholder expectations.
Release Burnup charts: For multi-sprint initiatives, these charts show story point progress toward release goals. You can visualize scope changes, track completion rates, and forecast delivery dates based on current velocity.
Milestone Burndown: Similar to sprint burndowns but focused on longer-term milestone goals, showing story point progress toward milestone completion and highlighting any scope or timeline risks.
FAQ
Q: Should every issue have story points?
A: Focus on estimating issues that contribute to sprint goals and team velocity. Small bugs, administrative tasks, or research spikes don't always need estimates, but user stories and feature work should be estimated consistently.
Q: What if our estimates are consistently wrong?
A: Estimation accuracy improves with practice. Review completed work regularly, compare actual effort to estimates, and adjust your team's baseline understanding. Focus on relative accuracy between issues rather than absolute precision.
Q: Can we change our estimation scale?
A: While Fibonacci is most common, teams can use other scales (powers of 2, t-shirt sizes, etc.). The key is consistency across your team and over time. Changing scales frequently makes velocity tracking less meaningful.
Q: How do story points work with multi-repository workspaces?
A: Story points work seamlessly across repositories within a workspace. Your velocity calculations include issues from all connected repositories, providing a unified view of team capacity regardless of code organization.
Q: What happens to story points when we split or combine issues?
A: When splitting issues, distribute story points among the new issues based on relative effort. When combining issues, add the individual estimates together. Update estimates if the combined scope changes the overall complexity.
Q: Should story points account for code review and testing time?
A: Yes, story points should reflect the total effort to complete an issue including development, testing, code review, and any other work required to meet your definition of done. This provides more accurate velocity calculations.