One of the most dreaded parts of long-term planning is the effort estimation process. How much work will it be to do the things we think we need to do?
When you find yourself in this situation, the most important thing to remember is that your goal is accuracy and getting close enough to the size of work, rather than precision, which requires detailed certainty about the small pieces that will make up the work overall.
To illustrate this, let me take you through a portion of my own yearly planning process. It starts bottom-up. Each subteam goes through their staffing and their desired project list, estimates the cost of the projects balanced against the staffing they have, and roughly sorts the projects into ‘the things we’re definitely trying to do’, ‘the things we might do if that other stuff goes faster than we expect or if we add people’, and ‘the things we want to do but probably won’t be able to get to’. These projects are then shared in document form, with descriptions of why they are important, and then a bunch of other stuff happens that ultimately turns into a plan for my entire organization. I’m going to skip the ‘bunch of other stuff’ for now and focus on the challenges and goals of this first step.
Identifying the project themes
The team is large, and as you break it down into subteams, and those teams break themselves down into subteams, you can start to get project lists that are quite granular: ‘project X which we believe will take one developer two weeks’, for example. For a team of three people, it’s not surprising that the leader can see plenty of small projects that will make up the work they expect to do. Left alone, I might end up with a project plan consisting of 200+ line items of sub-person-year work. This plan would seem to be very precise and measurable, and a good way to hold my team accountable for their work.
But it’s not what I want, so at this point, the directors go through and aggregate their team projects into larger chunks. My preference is to see nothing smaller than a person-year’s worth of work, and I like for things to be even larger than that. To do this aggregation, we need to scoop up all the little things and figure out a common theme to them so that we can talk about them as a collection. We lose a lot of the precision in the process, because that two-week activity is no longer called out. Instead, we have a bigger bucket that might be called ‘operational excellence’, tracking a bunch of small things we want to fix about the operability of a system, or possibly multiple systems, in order to get the aggregation to something that is a meaningful size.
Aggregate to support flexibility
This loss of precision can come at a cost. Sometimes those small projects are annoying things that are easy to forget, like upgrading a library, and we don’t notice that we’ve neglected that obligation until we are inconveniently reminded by a team that really needs it done. Then someone has to drop work that they’re more excited about to meet this obligation, or perhaps it doesn’t get done at all. And it’s much harder to hold a team precisely accountable for doing all the little things they said they would do at the beginning of the year, because that list is gone. All we have is a larger dedication of effort with a description of the purpose of this holdout and perhaps a few key outcomes we expect.
However, there are two huge upsides to this loss of precision. When you force projects into large enough groupings, you also force yourself to think about the common ‘why’ of the work. This ‘why’ is key because, in fact, we never predict precisely all the work we need or want to do a year out. The only constant about engineering is that things change. People leave the team, join the team, we learn something about customer needs, we realize that an approach is not going to work. Grouping the work into a ‘why’ means that you can change your mind on the details without having to completely restate the general commitment you made to this type of work this year. You committed a year’s total work of operational excellence, and it turns out you’ve found better ways to invest in that than you had at the start of the year, and that’s okay.
The other outcome is that, particularly for groupings larger than a developer year, you force the reckoning that you cannot do one project stream per developer and you must actually think about this work as teamwork. This is an obvious thing to say and yet it does not go without saying. Many teams still operate as parallel streams of developers working on their own things independently. Now, I’m not suggesting that you plan for pair programming, but particularly for long-running projects, you want to think about these initiatives as team initiatives, because you want more than one person to understand the work if you are to successfully maintain it for the future. Furthermore, it’s better to break a project up into parts that multiple people can work on in order to finish it before moving on to the next thing. Limiting the number of completely different projects in flight is a good practice for keeping coherence and productivity in your team, and gives you more opportunities to re-evaluate whether you’re working on important things. It also allows you to finish things faster, and realize their value sooner. (Yes, I am aware of the limitations of The Mythical Man Month, but these days many projects are amenable to parallelization).
Final thoughts
I have no doubt many of you are laughing at the thought of even trying to plan a year’s work with any accuracy or precision at all. This type of planning assumes a degree of stability that does not exist everywhere, and let’s be real, it is, at best, only mildly accurate. But the sentiment still applies. When looking to plan for anything longer than a sprint, think about how you can be accurate, not precise. What are the big areas you need to invest in? How much do you need to hold out for ‘keep the lights on’ work, like support, incident management, and upgrades? Don’t agonize over tiny details but work to understand the big picture and rough costs of those bigger elements, so that you can invest appropriately. Round up to wholes as much as possible, instead of expecting people to do fractional pieces of work all over the place. While it’s great to parallelize a project, it’s terrible to parallelize a developer unless you want them to lose a lot of time to context switching.
The next time you need to estimate work as part of planning, try to keep it simple. You might start with precision to sort out your thinking, but make your ultimate goal one of accuracy. Your plans should reflect a sense of what is important, why it is important, and a solid investment that reflects the importance of the work. When your plans are grounded in the value of the work, you will find they can accommodate a lot of change and still deliver results.
