Thanks for sharing your question Chris. I generally recommend keeping product roadmap and product backlog estimates high-level. Estimating the roadmap should help determine cost or understand if the roadmap can be implemented by the development team. Determining the size of product backlog items facilitates prioritisation (taking into account cost-benefit) and allows tracking the development progress across several sprints. For estimating product backlog items, effort units like story points and ideal days tend to work well in my experience. But I would leave up to the development team to decide which estimation techniques they want to use.

Note that in Scrum, there is a another estimation and planning level: The dev team determines in the sprint planning meeting how many high-priority items can be implemented in the sprint. Traditionally, this is done by breaking items like user stories into tasks, estimating them in net hours, and using the collective capacity of the team to determine the right work load. Using more detailed estimates in sprint planning makes sense: The objective as this stage is to ensure that the sprint goal selected can be met without sacrificing sustainable pace.

Does this help?

In the section on Estimation Approaches, you say that the estimates should be high-level and you argue that breaking them down further at this stage is not overly productive or valuable (I’m paraphrasing here) because the estimate will not be accurate at this stage and will end in time wasted. In what values are the estimates made? Is it story points, t-shirt sizes, ideal person days, gut feeling, etc.?

Then there is a second round of estimating when the product backlog is populated. Again, in what values are the estimates made? How do these high level estimates get translated into a burn-down chart?

Will you provide a simple example starting at the the initial estimation phase and progressing into having a product backlog and a release burndown chart just prior to starting the release development?

Thanks!

Thank you for sharing you question, Peter. You can think of the product/release goals on a product roadmap as objectives and you can view the features as key results. In this sense, the planning approach described leverages OKRs. Please take a look at my article “Leading through Shared Goals” for more information on goals/objectives in a product context. Hope this helps and good luck with your new product!

Thanks again

Thank you for sharing your experience Dana. Great to hear that goal-based planning has been beneficial for you. One of the techniques I like to use is to schedule regular strategy workshops in addition to sprint review meetings in order to assess the product strategy and roadmap goals together with changes in the product performance, competitors, trends, and development progress and to adjust the plans as needed. Something similar might help you with your transition effort. Hope this helps!