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 story points 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 sprint assigned.)
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 sprint. Issues that have a sprint 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.
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
We encourage team members to utilize planning poker in Zenhub when estimating work. Planning poker is a consensus-based technique that allows teams to build more accurate estimates for issues. Zenhub's planning poker allows team members to do planning poker online asynchronously. This means team members can provide their estimate on their own time – right in GitHub. Learn more about running a planning poker session in Zenhub here
If you're looking to add a final estimate to an issue, open an issue in Zenhub. Once in an issue, on the sidebar will be a section for setting an Estimate.
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 reflects 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 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, click on the gear icon and uncheck the estimate, it will be removed.
Note: If you've used Planning Poker to add the estimate, and you want to clear the estimate from the issue, you'll need to remove the Final Estimate, then have team members remove themselves from the Planning Poker list.
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.
Learn more about agile estimation techniques here.