Software estimation – predicting the level of effort required to complete a development task – is a notoriously unforgiving chore. There are so many variables and downright unknowns in most software projects that making data-driven, reasonably accurate project estimates can seem virtually impossible.
Despite the headwinds, estimation is a fundamental and unavoidable element of software project management. Development teams rely on estimates to build achievable schedules and prioritize work, product owners rely on estimates to build product roadmaps, and management relies on estimates to set and track budgets.
In Agile, we approach software estimation within the same philosophical framework we use to attack other project management activities.
Agile estimation is based on simple, easily determined measures that are iterated and refined throughout the software development lifecycle. The results of this process are estimates that are often more accurate, and almost always more useful than those produced by other approaches.
ZenHub, our Agile project management solution for GitHub, provides built-in support to seamlessly implement estimation into your workflow. In this post, we’re going to take a deeper dive into the concepts and techniques of Agile estimation, and then show you how you can get started putting these ideas to work with ZenHub.
The Agile approach to estimation: Time vs. size
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.
Consider the quintessential Agile unit of measure: T-shirt size. Most of us could look at a T-shirt and make a good guess as to whether it’s small, medium, or large.
More importantly, if we were shown two T-shirts of different sizes and asked to decide which one is bigger, we would almost certainly get it right. If we were given a big pile of T-shirts and asked to sort them into three piles by size, we would probably do pretty well with that task too.
This idea of relative sizing is the fundamental driver in Agile estimation.
It turns out that just like we’re all pretty good at ranking T-shirts by their relative sizes, development teams are pretty good at ranking stories by their relative sizes.
In the same way we'd have a hard time guessing the exact width of a T-shirt, it can be difficult for development teams to guess exactly how long a task will take. Instead, just like how we'd find it easier to rank T-shirts by their sizes, teams are better at ranking stories and work by relative size.
Story points and estimation scales
Although many teams find project estimating with T-shirt sizes easy and intuitive, many teams ultimately choose to go with numerical project estimates that allow for quantitative calculations. Story points are Agile’s numeric equivalent of T-shirt sizes.
Using story points, each estimated story is assigned a value such as 2, 3, or 5. Although we’ve switched here from the pure abstraction of small, medium, and large, it’s important to remember that story points are still a relative measure. A value of 3 is meaningless by itself. All we know about a 3 is that it’s larger than a 2 and smaller than a 5.
Story point values are selected from an estimation scale. One of the most common scales, and the one used in ZenHub by default, is called the Fibonacci scale: 1, 2, 3, 5, 8, 13, 21, 40 (The mathematically literate will note that this range of numbers is similar, but not identical, to the Fibonacci sequence, but that’s a story for another day.) Something important to observe about this scale is that it’s non-linear, with the gaps between numbers increasing as the numbers get larger.
The increasing gaps in the Fibonacci scale are useful because as stories get larger, there are more uncertainties and estimation becomes more difficult. Generally, stories at the largest end of the spectrum are considered too large to reasonably estimate. These stories would be assigned 40 story points and be flagged to be broken down into smaller stories somewhere down the line.
Velocity is a measure of a development team’s rate of progress. Just as you might express your rate of progress in a car in terms of miles per hour, in Agile we express velocity in terms of story points per sprint (iteration).
Velocity is calculated by simply adding up the story points of all the stories completed by a team in a sprint. Consider that a team completed a 3-point story, a 7-point story, and a 10-point story during the prior 2-week sprint. Adding the three stories together gives a velocity of 20 points.
Velocity becomes a useful measure when we make the assumption that, over time, teams tend to complete a similar amount of work in each sprint. We can use this information to plan better sprints with more realistic, accomplishable expectations.
Theoretically, we can also add up all the story points for all the desired project features, divide that number by the points completed per sprint, and come up with a total that tells you how many sprints are required to complete the project (Total Points / Velocity = Sprints). So if the points completed for the current Sprint is 20 and the backlog has 100 points, the team will need about 5 sprints to do the work (100 / 20 = 5).
A benefit of using velocity and story points to build estimates is that the process separates estimation of effort from the estimation of duration. This distinction makes it much easier to update estimates over time, and the process can even be seen as self-correcting.
Consider that after the first sprint of a project you expected a velocity of 20, but after the next three sprints it turns out that the velocity is actually 15. The refined velocity can be applied to the remaining backlog for a more accurate estimate of the number of sprints required without necessarily needing to revisit the original story point estimates.
Agile estimation techniques in software development
With some basic Agile estimation concepts under our belts, we can turn our attention to how these concepts are put to use. There are a handful of tried-and-true techniques that Agile teams have developed over the years. We’re going to explore two of them, Planning Poker and Affinity Grouping.
But first, let’s run through a few of the guiding principles behind any good Agile estimation effort:
- Agile estimation is a team sport. It’s 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.
- Agile estimation techniques compare the story being estimated to other stories that have already been estimated. They use the concept of relative sizing to triangulate toward a valid estimate for the new story.
- Agile estimation should judiciously apply just the right amount of effort needed to get a good enough result. Try to avoid overthinking the estimate or spending too much time diving into technical details.
Getting bang for your estimating buck
The last point above, the need to be efficient in your estimation practices, is critical to the Agile mindset. Software estimation suffers from the phenomenon of diminishing returns. There are basic, simple Agile estimation techniques that can produce fairly good results.
Beyond those project estimation techniques, you can expend tremendous additional effort with little or no demonstrable improvement in the estimate. It’s impossible to drive all uncertainty out of the estimation process and therefore there is an upper limit to the accuracy you can achieve. In Agile, we acknowledge this fundamental limitation and embrace simple estimating methodologies that give us the information we need to support effective planning.
Planning Poker is perhaps the most popular estimation technique, and most Agile teams use some variation of the approach.
Planning Poker is an exercise that involves the entire development team. Traditionally, each member has a deck of cards that shows the numbers of the story point scale.
As stories are reviewed, each team member silently arrives at a score and then all team members reveal their selected card at the same time. The team then discusses the scoring, and members contribute their rationale for the score they awarded. After discussion, the team again votes with their cards. The goal, and typical outcome, is to converge upon a single, agreed-upon score within a few rounds.
Affinity Grouping is an alternate method to Planning Poker in which team members group items into tiers based on relative size. The basic process is usually carried out with sticky notes on a board. The notes are arranged with smaller items going to the left and larger items to the right.
The backlog is taken one item at a time. The item is discussed in terms of how it compares to the size of items already on the board, and then placed on the board accordingly. The items arrange somewhat naturally into columns which become affinity groups. Story points are assigned based on the story’s affinity group.
This is a simple method of organizing your product backlog items one is fairly simple but only for estimating small user stories. Every person gets a definite number of dots (4-5) that can be used to vote on user stories. You can use an online tool while remote or a whiteboard when in the office.
The more dots, the more time and effort needed to complete the item. In the end, you should have a list of items sorted by their priority.
The bucket system
What about large numbers of user stories?
The Bucket System can be even more efficient and quick than Planning Poker when it comes to estimating task complexity.
Each person will add tasks to one of the available buckets based on their urgency and priority. After every team member has divided the tasks, these will be reviewed together to reach a consensus.
Here’s a detailed look at the process in action:
Validate and refine your project estimates
We’ve talked about how velocity adds a self-correcting component to estimation. As a project rolls on and we learn more about team performance, velocity helps drive us to better overall estimates without the need to update our fundamental story-by-story size estimates.
However, recalibrating your velocity won’t help your project estimates much if your team is not sizing well to begin with. If your team is routinely missing the mark on sizing – saying that hard jobs will be easy or easy jobs will be hard – then more proactive steps are in order.
Retrospectives are an Agile best practice and the perfect time to review estimation performance and discuss root causes of estimation errors. Ideally, your team is doing a retrospective after every sprint.
Since story point estimation is based on relative sizing, it can be helpful to compare like-to-like in retrospectives. A common approach is to select two or three completed stories with the same point value and step through those stories as a group.
A common approach is to examine the completed stories that were originally assigned the same estimates, and reflect on whether these stories did end up taking similar amounts of effort. If not, the team can try to determine what might've contributed to this discrepancy.
Were the stories well-defined? Did the team consider the effort of related tasks, such as testing? Is the team being too optimistic about certain types of work?
If your team routinely works through difficult questions like these, over time estimation should become more consistent and reliable.
Agile estimation in ZenHub
ZenHub makes it easy to apply story points, velocity, and other Agile concepts to your estimation and planning activities.
Story points can be assigned directly to any Issue in the backlog. When you’re viewing an Issue, project estimation is available to you in the sidebar, where you can select the story point value from a dropdown. ZenHub uses a Fibonacci estimation scale by default, but it’s easy to customize the scale if desired.
Once you have an Estimate assigned to your Issues, this data becomes available throughout ZenHub. For example, you can filter the board by Estimate to see all the Issues of a certain size.
Estimating your Issues also allows you to gain insights using our suite of Reports. ZenHub’s Burndown Charts, for example, pull in all the estimated stories from a GitHub Milestone (sprint) to give you a visual representation of the in-progress sprint. You can see what has been completed and what remains unfinished, and you can assess how the team is performing against what was originally planned.
Once you have a few closed Milestones, ZenHub automatically builds a Velocity Chart, allowing you to use historical velocity to predict future trends. These reports show the last seven completed Milestones. The Velocity Chart allows you to quickly see how consistently the team has been performing and to easily drill down into Milestones for greater detail.
ZenHub’s default settings and automatic integrations make it easy to jump in and use Agile estimation for your GitHub projects.
To learn more about getting started with software estimating in ZenHub, download our free ebook: Better Software & Stronger Teams.