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.
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.
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.
There are many ways to go about estimating software (we share a few of them here). Whether you use triangulation, planning poker, or some other estimation method, you should always remember to prioritize two things:
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.
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 estimate value from the Estimate dropdown.
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.
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.
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.
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.
Add extension to add ZenHub’s features to your GitHub interface. We never touch or look at your code, and only access basic information (like GitHub issue titles) so you can manage and visualize them with ZenHub!
ZenHub is incredible! Every little detail was thought of. Great job you guys.
Slick, streamlined and well designed. Great customer service too.
My first experience with ZenHub was absolute shock. Then a sense of giddy happiness when I realized that using Github had just become that much more awesome. The UI is so intuitive.
Great, more robust functionality than Trello but easier than JIRA. Github integration is awesome.
Awesome - no more Jira!
Ditched trello after I found this amazing plugin.