Story Points
Estimate issues with story points to improve sprint planning, velocity tracking, and automated sprint capacity management.
What story points are
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 on a relative scale that helps teams plan more effectively.
In Zenhub, story points power several features including velocity tracking, sprint burndown charts, automated sprint capacity management, and team performance insights. When you estimate issues consistently, 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, though actual time may vary based on team member expertise, external dependencies, or technical complexity.
How to add story points
You can estimate issues in several ways depending on your workflow.
From the Work Tracker
Click on any issue card. In the issue details panel that opens on the right, click the Estimate field, enter your story point value, and press Enter. The estimate appears immediately on the issue card.
From GitHub (with browser extension)
When viewing an issue 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 directly.
Bulk estimation
Select several issue cards on the Work Tracker using Ctrl/Cmd + click, then apply estimates to multiple issues simultaneously. This speeds up backlog grooming sessions considerably.
Planning Poker for team estimation
Planning Poker provides a collaborative way for teams to estimate issues together, reducing individual bias and improving accuracy. It works 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 submit their estimates privately before revealing them simultaneously.
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 wide variance, 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.
Story point scales and best practices
Most teams use the Fibonacci sequence because it reflects the increasing uncertainty that comes with larger estimates. The gaps between numbers widen as estimates grow, 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. Common sizing 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 need to be split into smaller issues
Keep estimates consistent
Story points measure the work, not the person doing it. A junior and senior developer should estimate the same issue identically, even though their completion times will differ. If you discover during implementation that an issue is significantly more or less complex than estimated, update the story points to reflect reality — this improves future accuracy and keeps velocity data meaningful.
Integration with Zenhub reports
Story points feed directly into Zenhub's reporting suite.
Sprint Burndown shows story point completion throughout a sprint, helping teams track whether they're on pace to complete their commitments.
Team Velocity tracks story point delivery over time to understand capacity trends and plan future work more accurately.
Release Burnup shows story point progress toward release goals across multiple sprints, including scope changes and delivery forecasts.
Milestone Burndown tracks story point progress toward longer-term milestone goals, highlighting 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. 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 across all repositories within a workspace. Velocity calculations include issues from all connected repositories, providing a unified view of team capacity regardless of how code is organized.
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 and update 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 total effort to complete an issue including development, testing, and code review — everything required to meet your definition of done.