Help Center

Learning to estimate for the first time

We make it simple for teams just getting started with story points and Scrum to get started with Estimates in ZenHub. Whether you'd like a refresher, or are trying estimation for the first time, we've shared our framework for getting started below. 


An intro to story points and estimates

Have you recently had a feature discussion meeting where you've left with more questions and uncertainty than when you started? Estimation helps makes those unknowns easier to action and avoid next time. People are inherently bad at guessing how long it would take to complete a project without having a point of reference. It becomes much easier to provide an estimate if it gets compared with a project previously done.


By estimating work with story points, you create a shared understanding of how difficult a piece of work will be to finish. This allows individuals with different skills and experience levels to agree and understand how hard something will be to implement. This helps eliminate some uncertainty around how long complex projects will take.


Assign your first few estimates by assessing recently closed items and your top 3 backlog Issues

Look at what’s coming up in your sprint backlog. Select your top 3 highest priority sprint backlog items. These Issues will have more details, making them better understood by the team. 


By default, ZenHub uses a popular scrum method of estimating, the Fibonacci sequence. This sequence starts at 1 and ends at 40. This is because estimation is done by using a scale that exponentially grows. The higher the number, the more risk, unknowns, and dependencies there are with the Issue. 


The highest value estimate, 40, means that the Issue you’re looking at is simply too big to estimate and you need to break things down into smaller Issues. Where as a 1 means that it’s a really easy task for anyone in the team to finish.


To define what a 1 means for your team compared to a high-risk Issue, set up a time with your team to look back at big chunks of work that you have recently completed.

  • Choose one of the easiest Issues you’ve recently closed: assign this a story point of 1.
  • Choose the most difficult Issue you’ve recently closed: assign this issue a 21 


Remember, the highest estimate value 40 should be reserved for Issues too undefined or unknown. Use this as a visual cue to the team that it shouldn't move forward until there's a discussion to break it into smaller Issues.


Next, look at your highest priority Backlog Issues and discuss as a team how easy/very difficult each Issue is compared to the two Issues you just assigned a 1 and 21.  Use your next few sprints as a way to define what each value in your estimation scale means relative to the work your team does. 


One of the key differences with estimating using story points, over tracking the number of hours something will take is that story points are relative to each other. This means you have to constantly talk about Issues relative to each other to get familiar with story points! 


As a benchmark, here's our framework for what the estimate values mean in relation to Issue complexity:

  • Issues assigned 1 or 2 should be very easy, well understood, and have zero risk associated with them.
  • Issues assigned 3 or 5 are considered moderately complex, might have multiple ways to fix them or approach them, and might have some technical risk associated with them.
  • Issues assigned 8 are seen as quite complex, and should prompt further conversation from the team to figure out how they can break down these Issues into smaller, more manageable tasks.
  • Issues assigned 21 should likely be an Epic, signalling this is project-level Issue.


You can also get started by using small, medium, large scale represented by 1, 2, and 3 to keep things basic. Learn how to delete, and add new custom story points to the Estimate dropdown.


When to use high value estimates

To make estimates as accurate as possible as you get started, work should be broken down into as small of chunks as possible. Creating smaller Issues helps teams better prioritize what needs to be delivered when, and protects against accidental dependencies mid-development that create roadblocks.


When estimating a piece of work, if you’re assigning one of the highest value story points your team uses, or if you're getting started with ZenHub's default scale using either a 21 or 40, it’s typically a sign that there is either too much work in one Issue or there’s too much uncertainty. 


The smaller the estimate, the higher the degree of confidence it can be assigned to a Sprint and finished on time. This is due to a few key reasons:

  • Smaller issues have more clearly defined details. The more specific you can be bout exactly what needs to be done, the more likely it is team won't accidentally miss something before merging.
  • Smaller issues should have less technical risks. Because small Issues should have a high degree of detail clarity, there should be less dependency risks for technical complexity that might not otherwise be known when first starting work on the Issue
  • The smaller the Issue, the easier it is to learn from past Estimates. You should revisit old estimates every few weeks when getting started to understand whether a 1 was actually a 1. Compare two Issues you estimated as a 1 and ask, "Where these as hard as each other or was one more complex than the other?" If one is more complex than the other, update the estimate and share why to help the team get more familiar with the story point scale.


It’s important to re-visit the accuracy of previous estimates. 

Every 2-3 sprints when you're just getting started, have a quick 30 minute meeting to compare estimates on Issues in previous sprints. This helps your team re-calibrate. It also helps your team have conversations about how to create better-defined Issues from the start to avoid large-undefined pieces of work later in the development cycle. 


We recommend during your next backlog planning session, review the previous sprints' closed work and close you were with your original estimates. By talking about how hard something was to develop compared to how hard the team believed it would be, you can refine next Sprints’ commitments because of a better baseline. 


Having a backlog review every few weeks also gives teams a way to ask questions ahead of time if anything is unclear to avoid discrepancies in upcoming work.


Building a Burndown Report

After adding story points to Issues, the next step is to use GitHub Milestones to track what's in progress and upcoming. GitHub Milestones create ZenHub Burndown charts to help teams understand a few key insights:

  • How much you're committing to within a set duration of time
  • The ideal speed at which the team should be completing work across that timeline to get everything done
  • And, how the team is actually completing work

When comparing the actual speed of completion against the ideal timeline, teams get early indicators of how a group of work the team committed to is coming along.


Why Estimates are needed to build the Burndown

In ZenHub, Sprints are defined using GitHub Milestones. Each Milestones gets its own Burndown Chart. To build a Burndown chart, the Milestone needs:

  • A start and end date
  • Estimated Issues

Estimates provide information on how complex a piece of work will be to complete. By assigning a group of estimated Issues to a Milestone, you track your team’s throughput. The Milestone's start and end dates add in Velocity, or the speed at which you can complete work.


By knowing how much complexity you can take on in a set time frame, you’re able to better predict project releases.


Reading the Burndown chart

Along the middle of the graph is a light-grey, dotted line—This line represents the speed at which you need to be closing or completing Issues to complete all Issues you've set out to achieve. You can be confident you’ll achieve your goal if your team’s completed work closely aligns to, or is below this diagonal timeline.


Purple dots will appear above or below the grey line as they get completed. Only Issues that are estimated will make the line drop to zero. Un-estimated Issues can be added to a Milestone, but they won't count towards the Y axis. The Y axis is created by the sum of all story points assigned to Issues in the Milestone.



If you do not use Closed as 'done' you can use the Burn pipelines option on the top of the chart to set which pipelines represent work that your team views as 'done' in the Sprint.



Sprint review: suggestions on what to discuss after your Sprint ends

After your Sprint, it's important to discuss how things went. Here's a few recommendations on key questions to be sure to discuss as a team, especially as you first get started with estimation and sprints:

  • Did we accomplish everything or did we take on too much? This is important to understand if work wasn't picked up because you took on too much (perhaps take on 1 less Issue next time!) or if there was unforeseen technical issues, meaning the original estimate wasn't the right one.
  • Were the original estimates we assigned accurate? What was more complex, and why? What was easier than we thought, and why? Be sure to document these learnings in a central location to leverage for the next Sprint's estimation session.
  • Anything we want to change for next Sprint? This is known as Kaizen—It's the process of nominating an internal improvement to help the team work better together. Perhaps you want to polish your definition of done, review your code-review process, or establish a 1-Issue in progress limit for the next sprint. 


Using Velocity charts

As Milestones get closed, the Velocity Chart will automatically be built. Velocity tracking gives insights into how much you can reasonably commit to, and accomplish, each Sprint by taking the average amount of completed work across the last 7 closed Milestones. Learn more about Velocity


Did you find it helpful? Yes No

Send feedback
Sorry we couldn't be helpful. Help us improve this article with your feedback.