A Different Approach To Estimation & Tech Debt Prioritization

Problem

"Many years ago I was leading an engineering team of about thirty people who were working on a five-year program replacing an old legacy system in a large enterprise. We had a program manager who didn't really understand the technical details of what we were building and was managing 'by the numbers'. The program manager was plotting the team's estimates in MS Project and using that as a contract to punish the team when any estimates were incorrect. Some might think this is a reasonable approach, however the team was juggling building the new system, while maintaining the existing system, and fixing tech debt along the way - all in a very complex domain. The program was behind schedule, the Program Manager was not happy, and the team was demotivated. We needed a new approach."

Actions taken

"As we stepped back to analyze the problem, we realized that we had 'work requests' coming in from three different avenues; new functionality that the business wanted, operational issues (i.e. bugs) within the existing system, and a lot of tech debt that needed to be resolved as the team was moving quickly. The challenge was building a roadmap that accounted for all these inputs. The team came up with the hypothesis that it would be easier to manage the prioritization and development of tasks if we broke everything down into similar size work units, instead of estimating tasks. In order to test this hypothesis, the team went through the exercise of breaking down all the current feature requests into similar size chunks. If there was a big problem we would break it down into smaller pieces to make everything, as much as possible, the same size. Next, we put everything into a backlog - all similar sized chunks of our new features, operational issues, and tech debt. We then developed a few of the similar sized tasks to get a sense of roughly how much effort was required to complete a task. When we had a good sense of the tasks and similar sizing we were able to create a backlog which the business stakeholders could prioritize effectively and the program manager could build a roadmap of predictability. This brought to light another challenge of articulating the value of resolving tech debt to the business stakeholders, who constantly prioritized new features and resolving operation issues over cleaning up tech debt. To resolve this, we split tech debt into two categories; (1) small refactorings which we could complete in between feature creation tasks and (2) large modernization projects which required more analysis and effort. For example, there was one area of the codebase which over time had grown large and messy. We needed to refactor it into a smaller set of independent services, however this was no small project. Instead of trying to squeeze it in between other tasks, we created a business case identifying the effort required, the risk to the business if it wasn't completed, and the efficiency gains they would get from the engineering team if we were able to complete the work. We then presented the business case to the project stakeholders and got approval to add the modernization tasks to the prioritized backlog."

Lessons learned

"Firstly, as we broke down our work into similar size units, we continued to estimate against these work units, so that we could compare and contrast the results once complete. Upon comparison we found that the team was much better at same-sizing tasks (pattern matching) than it was at estimating. As an engineering team that's faced with tech debt, it's important to be able to identify the effort required, the risks of not doing the work, and the efficiency gained in a business case. This allows the business to make an educated prioritization of what work to do when."