It’s 4:30PM on a Friday and the Sales representative working with your department says “I have a client meeting Monday – can you tell me how long it will take to implement the new feature we talked about today?” Groan.
Off-the-cuff estimate requests can be stressful; are you better off to overestimate and risk a long explanatory conversation? To give a quick estimate and cross your fingers you won’t be held to it if you discover there was a lurking dependency? Does “I don’t know” send the message that you are unable to plan reliably?
Planning Theory
There are many brilliant and in-depth articles out there explaining more eloquently and in greater detail the theory behind planning successes and failures. An excellent example from Mary Poppendieck can be found here. In her presentation, Poppendieck suggests that meticulous plans spanning months into the future fall apart when cascading dependencies or changes in direction subvert careful calculations. Interruptive work that is the newest hair-on-fire-priority push planned items behind schedule or, more simply, estimates can be wildly inaccurate.
So why plan at all? There are parts of your business that will always need timelines. Your board will want to know when you expect to go to market. Sales will need to reliably tell a prospect when they might expect a prototype. Marketing will need to plan campaigns to line up with a major release. Other departments with dependencies based on your work will need to know when to expect your team’s portion, so you may as well foster harmony and learn to estimate accurately.
Timelines are hard to predict accurately
You can’t plan for everything, and interruptive work skews carefully made predictions, but if we allow every fire that crops up to push out planned work, we cannot reliably deliver on what we’ve committed to during planning. If we hold fast to planning, the machine runs smoothly but a given fire may burn for a while before it’s resolved. Additionally, any schedule has the potential for cascading delays based on dependencies. Waterfall methods which necessitate one team finishing their work before another even starts can result in pushing a careful year-long plan off target every time something is delayed by even one day.
Consider this scenario: Design promises completed wireframes, specs, and components in two weeks. After three days’ effort the team realizes there’s a cleaner, more user-friendly option and they have to rework some of what they’ve already completed. Now, Engineering is going to get the work two days later than expected, but they still need the three weeks they quoted and don’t have wiggle room to “save” the two days back. Worse, some stomach bug is sweeping the office and now the whole project is five days behind schedule.
Estimation is plainly and simply a skill that can (and needs to) be honed.
The Fibonacci Method
One of the benefits of sprints and other short planning periods is the very fact that you have a built in opportunity to stop, reassess the situation, and change direction as needed to reduce the impact of cascading delays. We use the Atlassian stack, so we’ve adopted their terminology (Sprint, Scrum, Project, and Board are in heavy use in my vocabulary)
At SpiderOak we’re running on the theory that “time” is inherently trickier to predict than “effort”. “Time” may vary for similarly difficult tasks depending on how much concentrated time is devoted to it, or whether the difficult part is the planning stage or actual implementation. Additionally, if work changes hands at any point, one person’s “week of work” could be twice as much time as someone else’s. We instead have opted to track “level of effort” (LOE) as our back of the napkin estimation technique. When we plan a sprint, every ticket is assigned “story points”. We use the Fibonacci sequence (1, 2, 3, 5, 8, 13, with our scale ending at 21) to determine "level of difficulty" in story points. The idea is that it's much easier to decide quickly if something is five versus eight points than it is to decide if something is five rather than six points. If a developer is unsure whether something is “five ” or “eight”, we encourage them to err on the side of caution, especially when they are first getting used to this system.
Ivan Bienco, one of our developers, created the following table to help explain the Fibonacci Method to new onboards:
| Points | Measurement of Problem |
|---|---|
| 1 | Easy |
| 2 | Slightly harder |
| 3 | 2 level work with "risk". |
| 5 | This may take a week to complete. |
| 8 | This is likely greater than a week's worth of work. If the task proves any bigger it will need broken down. |
| 13 | I have an idea but this needs to be broken down. |
| 21 | OH MY GOSH I HAVE NO IDEA. (Whether because no research has been done, the problem is too complex, and/or it may involve research and exploratory work |
The rule of thumb we use is that each senior developer can action about five points worth of work in a week’s time. It follows, then, that a developer who is onboarding or at a junior level should plan to take two to three points per week until they are fully up to speed. This allows us to estimate level of effort somewhat statically across a squad (this terminology is borrowed from Spotify. Full explanation here), while still accounting for differences in skill level across participants.
At this point in our process, we’re using three week sprints and planning for two weeks worth of work. We do this knowing that while we’ve gotten quite good at estimating developer and design effort, we are not quite confident yet in our ability to estimate other factors such as the time it takes to do code review or to triage and resolve bugs found by QA. Additionally, we acknowledge that some active time will be taken up by meetings that, while valuable, reduce the amount of time available for coding.
Another thing we rely heavily on is breaking tasks down to their smallest parts. We’ve found that at higher LOE estimates, the level of risk is higher. For example, our likelihood of running into unforeseen and unforeseeable items on a ticket of 13 points -- which we define as “more research needed” -- is much higher than a ticket of two points. Our developers have found that breaking 13 and 21-point tickets down into smaller actionable tasks makes planning much more reliable.
Who predicts level of effort?
Each of our departments is responsible for predicting the effort involved for their own work. We operate under the theory that only the people who will be responsible for completing the work are aware enough of the intricacies involved to give a good prediction. If I am responsible for predicting a timeline in a meeting without squad representatives present, I will refer directly to their scrum board to estimate future effort, based off their own previous predictions. If LOE estimates are not yet available for any reason, I will state that I cannot accurately predict how long the feature will take. I may give an estimate of how long until I will know or give historical precedent for a similar feature as a guideline, but confidence in our predictions are dependent on making sure the people doing the work are the ones predicting timelines.
So what's the takeaway?
Off-the-cuff estimate requests can be stressful, but they don't need to be. If your system provides a shared vocabulary for estimation you can reduce the panic that comes with a 4:30PM question. Our advice is to codify what "effort" means within your organization, practice estimation regularly, and encourage your staff to take some time investigating before committing to timelines. So maybe now you have some tools to answer that "... can you tell me how long it will take to implement...?" question. "I'm not sure yet. Without looking at the tickets more carefully I'll have to call it an 8. It should be a fairly simple fix, but we haven't investigated it yet so I'd prefer to give you an estimate that allows for risk."
