The executive team funds your product team. Delivering what you promised on time and on budget lets them know their investment is being well managed. This gives your team the space to execute against your product strategy over multiple releases and return the business results needed for continued investment in your product. Further, by developing a reputation for consistent releases, you’ll be forgiven for the occasional missed date that aggressive teams inevitably face.
Delivering on time, however, is easier said than done. Agile gives us velocity, also known as yesterday’s weather, to understand how much work we have and how to balance that with our team’s throughput. It’s good for planning the next couple of weeks of work.
Agile also tells us not to plan too far ahead because those plans will change as our knowledge increases through the process of building the product and gathering feedback as we go. So even if we track our team’s throughput and know our velocity, if planning is emergent, it’s reasonable to ask how one could ever expect to achieve predictability on a large product initiative?
Think about a Project as a large-scale product initiative spanning multiple quarters, a Release being a major set of new capability added over a planning cycle of 90 days, and a Sprint representing a finished set of stories over a couple of weeks to a month. These can be adjusted to match the rhythm of your company and product team as well as your development method – be it iterative such as Scrum or continuous flow such as Kanban.
There are also a few data points that need to be tracked and periodically analyzed. It’s not a lot of work, but without the data your product team is flying blind. Start by breaking down the project into epics (i.e., big chunks of functionality). Quickly size those epics relative to each other. T-Shirt sizes or months works well. Then decompose whatever part of those epics will make up the next release and continue to split those capabilities so they are between a week and a month in scope. Finally, create a backlog of stories for the next two weeks to a month that are sized between two to three days of effort, up to five days at most. You may now have four quarters planned at the Project level, three months planned at the Release level, and two to four weeks planned at the Sprint level.
Now start tracking. If you use story points, make sure stories that enter development all have points. If your team does not estimate or is not consistent about its estimating, then just count stories. Keep track of how many points and stories the team completes in a Sprint and Release and how many points and stories made up each epic when it completed.
At this point, you should begin to have a picture of how your system works. But there is one more key step because not all stories are the same.
Join us on August 30th for our co-hosted webinar with AIPMM, Predictable Delivery: The Power of Estimating and Forecasting, to learn more about achieving predictable delivery and the different story types that you need to track to improve the accuracy of your forecasting.
Want to increase your skills as a Product Manager or Product Owner working with an Agile development team? Consider taking our Agile for Product Managers and Product Owners training to better enable your team for success, and more effectively take advantage of the benefits of Agile development.
NOTE: This webinar has passed – you can view the slide deck below.
Most product teams don’t fail because they can’t ship. They fail because product discovery didn’t do its job. As product managers and product leaders, we’ve all lived this
Product management feels harder than it should It’s not because teams are lazy. Not because PMs
By the time a product launches, most teams feel like they’ve crossed the finish line. In reality, that’s where
