Help Center

In 2011, researchers at Microsoft released an award-winning paper that examined estimation techniques used by their teams over long periods of time, comparing those estimates against their actuals. You know what they found?


All estimates are wrong (but some are less wrong).

All estimation techniques are flawed, but some were more wrong than others. Time-based estimates done by individuals not doing the work were the most wrong.

The Least Wrong Estimation Technique

However, Microsoft’s data showed that there was one technique that worked better than others. The least wrong way to estimate is also fast and easy to adopt. To practice the least-wrong way to estimate, have your team:

• Work together for a few weeks

• Get some stuff done

• Review the work done

• Pick an “average” or “medium” piece of work (in terms of effort)

This “medium” piece of work becomes your comparison point for estimating effort. It should be:

• Completed within a sprint 

• Not too easy

• Not too hard


If this piece of work was a t-shirt size, it would be a medium. For most ZenHub Users, a medium-effort story is a 5-point story (we use the Fibonacci sequence mapped to T-Shirt sizes for our estimates).


When you have a new body of work ready for the team to review and estimate the effort involved, ask the team if they think the new work is more or less effort than the established “medium.” Then map the t-shirt sizes to the Points in Zenhub.





Story point vs. time estimates

In traditional software project management, estimates are based on the question “How long will it take?” In Agile, estimates are based on the question “How big is it?” While at first glance the difference in approaches might seem subtle and even a little arbitrary, this reframing of the question from time to size turns out to be a real game changer. People are mediocre at guessing how big something is in absolute terms, like hours or days – but are surprisingly good at sizing something up in relation to another thing. If you give a person two piles of beans, they probably won't be able to tell you how many beans are in each pile. However, they should be able to say one pile is about twice the size of the other pile.


That's the basis of story points. They're unitless scales of measurement which are sized in relation to other tasks. The purpose of stp is to compare a task in relation to the sizes of your other tasks. This idea of relative sizing is the fundamental driver in Agile estimation.


When should you estimate?

There's no perfect answer to this, but here's what we recommend.

Before anything is ever estimated, GitHub Issues should be broken into more granular chunks as some discovery work has been done. Probably, that means they're ready to go in the product backlog (the backlog pipeline without a Milestone.)


Check out our eBook Focused Teams to dig deeper into Software Estimates


Adding story point estimates at this stage will inform the next step: deciding which Issues to add to a Milestone. Issues that have a Milestone and an estimate will appear in your reports, like Velocity Charts and Burndown Charts. As a result, you'll be able to see how your projected team velocity compares with reality.


add-estimates


How should you estimate?

There are many ways to go about estimating software. Whether you use triangulation, planning poker, or some other estimation method, you should always remember:


  • Agile estimation is a team sport. It is considered a best practice to have multiple people participate in the activity to allow for differing perspectives on difficulty. 
  • Agile estimation works best with small units of work. Larger stories and epics should be broken down into smaller pieces.
  • Try to avoid overthinking the estimate or spending too much time diving into technical details.

Adding estimates in ZenHub

To get started with estimation in ZenHub, head to any Issue. Once in an Issue, on the sidebar will be a section for setting an Estimate.


Estimate GitHub Issues


By default ZenHub comes with default story point values that follow the Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21, and our own twist on the sequence to symbolify the largest story point value of 40. The Fibonacci sequence is a popular Scrum method to follow when estimating work to be done as the story point values get significantly larger numbers. Going from quite small values to significantly large numbers reflect the uncertainty of estimating larger items.


Customizing estimates and story point values

Need to customize the story point options in the Estimates dropdown? To delete an existing story point option from the list from the list of options hover over the story point. Clicking the trash can that appears on the right of the story point will remove it from the list.


Deleting the story point will permanently unassign the estimate across all Issues where it has been assigned. Be sure to talk with your team before permanently deleting a story point option.


If you need to clear the estimate from the Issue, select the Clear estimate option at the top of the Estimate dropdown.


How do I clear a story point assigned to a GitHub Issue?


To add a new story point option simply type the value you would like to add as an estimate. This will prompt you to create a new value.


Sort Issues on the Board by estimate

Once you have estimated Issues, you can sort each pipeline on the ZenHub Board by story points. Click on the Sort pipeline option and select Estimate to get a complete picture of the estimates of most Issues in the workflow.




Estimate Issues en-bulk

Whether you are starting your Sprint or doing some cleanup on the Board, you can leverage the multi-select action bar to assign estimates to a grouping of Issues.







Did you find it helpful? Yes No

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