Estimating software is, essentially, the art of guessing. In agile development, the bigger a project is, the less accurate an estimate will be. The further away the delivery of that project is, the less accurate its estimate will be.
Accurate or not, people will still want to know when a particular feature will be shipped.
At the beginning of a project, estimates are bad guesses at best. In contrast to waterfall development, most agile teams now add detail about tasks as they discover more about the tasks and the project. You won't know much at the beginning of a project – and that's okay.
Why bother estimating software? Estimating a task is helpful when putting together your sprint backlog: given a set budget and a fixed amount of time, how could you tell which Issues to tackle if not for estimates?
Secondly, when paired with historical data (like Velocity charts), estimates illuminate how fast you're really moving – which is an important piece of insight for effective GitHub project management.
Story point vs. time estimates
Agile development deals mainly with two estimate types: story point and time. Story points involve relative estimation. 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. Unlike hours, which are based on consistent values, story points are based on arbitrary measurements. Their only purpose is to compare a task in relation to the sizes of your other tasks.
Agile projects prefer a point-based system for a couple reasons. You don't need to stress about how your “actuals” compare with your “estimates”. Relative estimates remind us that they're not meant to be used as a deadline.
In contrast, time estimates are useful only when you have enough information. You should only use them when your team has done some discovery work and gathered detail.
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 in the product backlog (the backlog pipeline without a Milestone.)
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.
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 to prioritize two things:
- The Team: Never estimate alone. Harness the wisdom of your team. Your estimates will be better, and your team will like you more!
- Speed: Remember not to get caught up in the tiny details, because you're still only guessing.
Adding estimates in ZenHubTo 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==.
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.
A high estimate usually means that the work being estimated is not well defined. This uncertainty can create misunderstanding. Work that gets assigned a high story point value should be broken down in detail or transformed into multiple, smaller pieces of work.
Once you have an estimated value in mind for an Issue, simply click on an estimated value from the Estimate dropdown.
Changing 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 remove the estimate across all Issues where it has been assigned. Be sure to talk with your team before permanently deleting a story point option.
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 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-bulkWhether 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.
For teams getting started with story point estimating we’ve created a helpful guide on how to estimate in agile project management. If you have any questions, you can reach out to our Customer Success team who are happy to walk you through how to start using estimates.