When we started with Scrum at Rally years ago, we used to just do a design meeting every few weeks with a couple of key stakeholders to talk about what was coming up and prepare the backlog. This worked relatively well, but as we added more discipline to our release cycle, the ad-hoc backlog planning our Product Owners were used to started to break.
If you want your team to be able to make a commitment around 8 weeks of backlog, you need to do somewhat more prep than you would with vanilla Scrum. And if you want your team to meet that commitment, you need a mechanism to manage your stakeholders to minimize backlog churn.
About a year ago, we chartered a Product Council to solve this problem. The Product Council is led by the uber Product Owner for each product, and consists of stakeholder representatives from all interested deparatments. This team operates as lightweight Scrum that grooms the backlog for the next release, working in 4 meetings that are 2 weeks apart.
Meeting 1: Retrospective on the last Release
The first meeting falls about a week after the engineering team does Release Planning. The Product Owners review the plans for each Scrum, talking through the stories for the stakeholders. We'll also highlight the work that definitely does not fit into the release. Usually we have commitments from the development team as to what will be delivered.
We then ask people to rate how they feel about the product (what we plan to deliver) and the process (how we decided). We tabulate these numbers, and then move on to a regular retrospective on the process - what went well over the last 8-week cycle, what didn't go well, and what should be changed going forward.
Meeting 2: Bring Your Ideas
In the second meeting, we hang the roadmap and various backlogs on the walls - usability, platform, deferred defects, technical debt, customer requests, etc. The Council spends about 20 minutes "walking the walls" - reviewing the roadmap and various backlogs. People add items they think are missing, shift items forward where necessary, and talk about issues and concerns. The purpose of this meeting is to identify those items the Product Owners should research for the next release - we usually leave with about 10 epics that need investigation.
Meeting 3: Presenting the Design Continuums
The Product Owners spend about 2 weeks researching those key epics, and come back with rough design continuums (backlogs) for each one and high-level estimates. In Meeting 3, they present these ideas. Sometimes an epic is too complex or unknown to be considered for the next release, or perhaps it's too expensive to build given it's value. The Product Council votes to rank the different epics.
Meeting 4: Presenting the Detailed Backlogs
Based on the voting from the last meeting, the Product Owners go off and begin blending the strategic epics from the Product Council with small customer requests, deferred defects, and other small items. In Meeting 4, we present the detailed, forced-rank backlogs that we intend to present to the development teams in Release Planning. We talk about what's changed and see if there are any last-minute, "Stop the line" type shifts that have to happen. We get a fist-of-five commitment from the Product Council to confirm their support for these backlogs.
Moving forward, I'll post more details about how these specific meetings work.
Posts
