Sizing software work appropriately has some challenges and pitfalls, but there are a few simple guidelines you can follow to help raise your level of confidence in your team delivering on time. First, you should [Make Sure You’re Building the Right Thing]. Next, [Learn How To Estimate Software Work]. We encourage you to use [Fibonacci Estimation for many reasons].
Assuming that much is straightforward (which it isn’t), as a team, you need to take work on that you can reasonably expect to complete.
How to Eat an Elephant
Step 1. Butcher the Elephant. Cut it up into tiny pieces.
Step 2. Cook and eat the pieces one at a time. Size each meal so that you can finish it in one sitting.
Step 3. Ship it.
In software, [Agile Methodologies] encourage us to break work down into small chunks. Much like eating the proverbial elephant, it’s not likely to go supremely well on your first go of it. Perhaps it won’t ever be done perfectly, but you can follow some guidelines to make sure that you have a high probability of success.
How Big is Too Big?
Your team’s estimation accuracy is likely to increase over time. When you start a project, there are too many Known Unknowns and Unknown Unknowns. There is much uncertainty — and uncertainty never contributes to accuracy. You need to start somewhere, which is why we say an estimate of a 1 is the simplest of all tasks. As you progress up the Fibonacci scale, by the time you estimate a task at a 5, you’re looking at 4 ordres of magnitude in complexity. That’s approximately 10,000 times more complex than the most straightforward of changes.
So why on earth would you be willing to take on a task estimated larger than a 5 on a Fibonacci scale?
Stop. Keep It Stupid Simple.
We strongly discourage any team from taking on a task estimated at more than a 5 in Fibonacci estimation of complexity. As the complexity of a task increases, the chances of Unknown Unknowns being encountered increases. If your 8 or 13 point task is the most important thing on the docket and “absolutely must” be completed in the future, you should know what to do:
Break It Down
Take your 8 or 13 point task, and start talking through the approach with your team. Split the item into as many individual tasks as appear reasonable and necessary to achieve the goal of the original story.
Start by breaking down the item, focusing the team’s conversation on what is involved in achieving success for the original task. Once you have an accurate picture of what the technical pieces in need of execution are, Once you’ve worked thoroughly breaking the item down into its discrete parts, have the team go through another round of estimation.
Important Side-Note: help your team avoid context switching by handling the breaking-down and the estimation of tasks separately. Once you hit a 13 pointer in the backlog, it’s worth breaking it down right away, because the team’s shared context has switched to wrap their head around this item. Proceed to break the item all the way down into seemingly reasonable parts. Once you’ve accounted for all pieces of the work item, then move back to estimating the discrete parts. [Humans are Terrible at Context Switching] so help your team out by avoiding it.
A typical 13 point story could likely be broken down into 5-8 different individual tasks. You may be surprised to find that as you break the issue down, the sum of the parts is equal to more than that of the original 13 point estimate. It’s typical to see estimates of the tasks involved in the delivery of a 13-point story to break down as 5+3+3+5+2+1=19. There’s nothing quite like taking something complex, making it simple, and then realizing there’s more work involved than you originally had thought.
Why Does this Matter?
When a developer sits down at their computer for a day’s work, (let’s say it’s 8 hours), it’s reasonably likely they can complete a 5 point item that is well defined and has few unknowns. As soon as you pass beyond the 5 point threshold, the uncertainty begins to increase and the likelihood of the work extending beyond one-day increases. It’s essential that the work not extend beyond one day because it’s easier to get work done when you feel like you’re accomplishing something every day. Long, slogging tasks are disincentivizing.
By keeping your team’s work items small, you should see higher team morale, not to mention more easily testable code with more isolated changes.