To make your roadmap dates realistic, you'll need to estimate the capacity of your team and the effort required for each milestone. It's not as easy as you think! Learn how to get it right.
- Now it's time to estimate the level of effort required to complete each of your product milestones. This will help you put dates on the roadmap that are as realistic as possible. You'll need to work with your product development leader on this. To start, you'll need a realistic estimate of the development capacity of your team. Usually, we measure these in developer time units such as developer days, developer weeks, or developer months. While it seems like the development capacity of the team would be obvious, after all, it's just the number of people you have developing multiplied by the time unit, you'll soon find out it's not so simple.
A typical product development team does a lot of things other than build new features and functionality. Typically, some of their time is spent on bug fixing, product maintenance, and engineering-driven projects. Ask your product development leader to estimate the amount of time the team currently spends on these items. Usually, it's easiest to compute it as a fraction of their overall capacity. Like 25% of their time on bug fixing, 20% on product maintenance, and 20% on engineering-driven projects. Once you remove the time spent on these items, whatever is leftover, in this case, 35% of the total, is the capacity available for development of new functionality for your roadmap projects.
The next thing you'll need to do with your product development leader is to estimate the amount of development time each of the milestones is likely to take. It's a good idea to capture this information in a spreadsheet. A typical layout might look like this, with one row per milestone and columns for the strategic objective, the milestone summary, the source, and of course, the development time. Now, since the milestones are much larger and more complex than a typical backlog task, it's going to be quite difficult for your product development leader to estimate the scope, and they might even be reluctant to try.
Be clear that you're not asking them or the development team to commit to these estimates, you're just asking for their best guess. In fact, it's a good idea to put this disclaimer at the top of your spreadsheet to remind everyone that you share it with that they are only time estimates and are subject to change. If, after scoping, some of the milestones are too small, it might not be worth listing them individually on the roadmap. In this case, you might want to try to group them together into a larger milestone that supports some element of the strategy.
And if some are too large, see if there's a way you can decompose them into smaller milestones while making sure that each still has an independent business impact. Once you're done with this phase, you should have a spreadsheet with enough information to build a product roadmap with milestones that are realistic for the team to complete.
This course shows how to build a product roadmap for your business—and gain critical stakeholder buy-in. See examples of what roadmaps might look like, and spend time learning the tools and techniques necessary to map the projects for your specific organization. Instructors Teg Grenager and Eldad Persky help you create strong, dynamic roadmaps that will ensure your team is working on the right projects at the right time.
- What is a product roadmap?
- Roadmaps in agile organizations
- Selecting stakeholders
- Researching customers
- Identifying milestones
- Estimating effort
- Maintaining the roadmap