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 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 we're 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. First of all, they're fast. You don't need to stress about how your “actuals” compare with your “estimates”. Relative estimates further 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.
Remember, time estimates refer to actual productivity of real people; though a “big” task is big for both Sarah and Jane, that same task could take Jane twice as long as Sarah. That's why it's so important that only your development team should be the ones estimating software!
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: