Estimating is probably one of the most challenging things we do in software development. That might be hard to imagine for those who aren’t actively involved in engineering. There is a lot of complexity behind infrastructure, code, deployments, and all of that other “magic” we create. To this day, estimation is one of those tasks that’s still an educated guess used to simulate the level of effort associated with a product. Keep in mind that our definitions in this article assume that the team is building software, but with some critical thinking you can apply it to building anything.

Since the information here is written in longform (a long and detailed article), I’m going to provide a list of shortcuts in case you are just interested in one particular section.

• Who estimates tasks?
• When we estimate?
• Why we estimate?
• How we estimate?
• How do you pick a size during grooming?
• If you want to learn more about agile?

Who estimates tasks?

Software Development Engineers estimate tickets, as they are the primary “owners” of the work required to be done in each ticket. Tickets are often referred to or categorized as a story, task, bug, or issue. However, we are just going to call them tickets given that most of us use a “ticketing system” to manage and organize our work.

When we estimate?

We estimate ticket sizes during grooming or refinement (depending on what your group calls it). Some teams are required to also provide hourly estimates for one reason or another. You should avoid planning hours during grooming. Instead, you should only ever discuss hour estimates when you get to the planning meeting.

If you are unfamiliar with Agile meeting structures, grooming is a session where the ticket workers debate the size of each task. Planning meetings are separate, to discuss who on the the team is going to take responsibility for the work in each ticket. Combining these meetings is highly ineffective if you are interested in accurate estimation.

Why we estimate?

Estimation is a tool that we use to control how much work we promise to stakeholders at the that will be completed by the end of each sprint. Estimate too small and not everything will be completed as expected, and stakeholder won’t receive what they are promised. Estimate too high and the team will run out of groomed tickets and have nothing to do. 

Some people say that estimating is pointless (pun intended), but seriously, some people don’t believe there is any value in estimating since we usually estimate wrong. After all, the very definition of an estimate is that its not guaranteed. I highly recommend you watch this video from LeadDev which speaks a lot about the benefits of estimation. An important takeaway from the video for the estimators, should be around estimation bias. It is the notion that humans naturally think we can do things faster than we actually can do them. I have some good news for you though. We have some tools and techniques you can use to be better estimators.

How we estimate?

We estimate ticket sizes in story points. This is an agile industry standard. It’s also scientifically proven to be a more accurate way of estimating task sizes than using hours. You can read more about this on the scrum.org article about story points. We typically estimate in points based on sizes like small (3) medium (5) and large (8). This uses a Fibonacci sequence which allows us to naturally understand that the larger the story points, the less accurate the estimate. Less common sizes are 1/2 which is extra-small representing tasks we are extremely confident in, and know they will take very little time. More frequently we run into the 13/21 point tickets which we effectively consider “too large” and requires breaking the work down into smaller tickets. After all, we just said that smaller tickets are usually more accurate. On very rare occasions 13 point tickets are accepted as is, because there is no good way to break up the work.

We do not estimate in hours. However, we do track hours at Meredith where I work, and because of this the Project Team also does an “hours calculation” using the story point sizes. In addition to that estimation we give developers flexibility to claim “a few more, or a few less” hours. This is because all developers have a different amounts of experience, and a different amounts of knowledge on each platform feature. If for example, you have never worked on a ticket regarding “recipes” before, you might opt to increase the hours of a 5 point ticket from 6 calculated hours to 8 planned hours. This does not change the size of the ticket. It’s important to understand that “size” and “time” are very different measurements, and while they may be related, they will never be equal. 

How do you pick a size during grooming?

This is of course, the most challenging part of the process, and it’s a skill that is learned and honed over time. It’s not something anyone is born with, or at least I haven’t met anyone born with this talent yet. Each team estimates a little bit differently because each software project and team is unique. All that said, there are ways to help engineers choose better story sizes. 

Story points define three aspects of a tickets size assessed by risk, complexity, and repetition.

1. Risk: If you haven’t estimated before, review previous tickets of each size, to get an understanding of the complexity of each ticket. Context is a great tool for estimation, especially since it gives direct insight into some of the unique parts of each software product.
2. Complexity: Think of sizes using rocks, because they have a notion of weight to them. A 3pt rock you might be able to hold in 1 hand, a 5pt rock you might need 2 hands to hold, an 8 point rock should be so big you can barely pick it up and move it around. This should also help you understand why we don’t like 13pt rocks, which are so big you really can’t move them on your own.
3. Repetition: Try not to think about time (hours) during your point estimation. This can frequently be challenging because many people moving to Agile come from place where hour estimation is required for every task. When there is a lot of repetition, think about when a single person may start to need help repeating

If you want to learn more about agile?

I did extensive research and development on an Agile approach to software development at Meredith and collected my findings into a “private” presentation during a conference called Pressnomics aimed at leaders of business that use WordPress. Since the conference was private, the presentation couldn’t be recorded, but my slides are available at this link.

You can also follow me on linkedin where I post my newest content.