Estimating large chunks of work
Balancing Projects, Initiatives, and the ever-elusive whole shebang
Modern-day software development is product-oriented. We build small increments that evolve our products to solve our customer's problems better.
Yet, at a certain point, every product team gets asked questions that hint at a more project-driven mindset.
"Can you estimate how long it will take to build a back office tool for our service desk?"
"How much time do we need to close all the integration bugs?"
"When can we decommission those pricy Windows servers?"
And it's here that our product mindset shows its limitations. While we can definitely create some tickets to refine the problem, it's hard for us to commit to a timeframe.
So, how do we handle this?
The first thing to realize is that these are friendly requests. They come from partners and stakeholders that want to see a certain problem solved. They do not come from customers that will sue you if you go over budget.
We're after ballpark figures, not exact math.
Then, we need to ask ourselves if this request is a pure project or a vague initiative.
A project has a fixed scope. When we deliver 95% of the project, it's still a failure. We need the whole shebang.
The Windows servers request is a typical example of a project. Our stakeholders want to simplify expenses and want to get rid of Windows licenses. If we migrate away from all but one server, their problem isn't solved. We need to get rid of all of them.
The way to estimate such a project is pretty straightforward. We refine the requirements, organize them in a Work Breakdown Structure, estimate each work item, and sum up the total. We add some contingency buffers, and we have our answer. Old school.
In the case of the Windows servers, we list all the servers that need to be migrated, estimate the workload for each of them and add those up for a total.
These projects should be planned in a Focus Block if the whole team can be involved. Often, however, only specific developers can help out with the project. In that case, we'll plan the project in an extended Recovery Block.
Sometimes, the stakeholder's request isn't a pure project, as there is no fixed scope. The example of the back-office tool for the service desk is typical. The first-line service desk has to contact the developers for every configuration and user management change. That creates a lot of operational work for the dev team that the service desk should handle. Management wants to know how much it would cost to reduce this workload.
This is an initiative that tries to address a ill-defined big problem. There's no point in trying to break down the work, as the scope on this one isn't fixed. We don't need to solve the entire problem; we need to alleviate the pain. It's a classic Product Management scenario.
Here we should interview people and find out which housekeeping jobs are frequent and take up the most time. We can rank those and decide how much appetite we have to solve this problem. We then plan a Focus Block to address it.
“We’re willing to spend two weeks with the entire team to reduce this pain.”
Estimating large chunks of work often feels intimidating. We fear scope creep and hidden complexity. Those concerns are valid for initiatives where we want to build ill-defined functionality. Pure projects, on the other hand, are much more predictable. We can remove a lot of fear by separating the risky feature work from the more stable project work and treating them like either initiatives or pure projects.
That allows us to give actionable ballpark estimates to our stakeholders without over-committing ourselves.