Scaling the Scrum Product Backlog
In its simplest, purist form, Scrum calls for the Product Owner to write User Stories, refine them with the various stakeholders, and present them to the team for grooming and estimating. However, in order to scale, this is often impractical, and the work of creating and refining the Product Backlog must be shared. This is further complicated when there are multiple teams working on multiple subsystems, and often multiple backlogs. Another challenge is added in regulated industries where various agencies may require highly detailed requirements and specifications be met and demonstrated with a Requirements Traceability Matrix or other auditable documentation.
One solution I have found to be very useful is to define a workflow for story development and create custom states for each handoff in the process. A Kanban board can be very useful to visually present the stories in each state.
For example, the Product Owner writes a few epic stories outlining the functionality they want to see for a particular feature. After refinement with the appropriate stakeholders, these may be passed to a Requirements Analyst to insert the “Thou shalt/Thou shalt not” regulatory or other acceptance criteria. These epics may then be passed to an Architecture or High-Level Design team to broadly define design parameters or add technical requirements for integration with other systems. They may also break it down into smaller story groups for assignment to specific teams. At this point, the stories should be ready for presentation and grooming by the teams, giving them the context and “big picture,” and made ready for estimation. Simple status labels such as “In Process” are rarely sufficient for such a workflow, with multiple resources iterating through layers of refinement needing to be tracked in order to maintain the flow of the Backlog “pipeline.” The screenshot below depicts one process flow for doing this.
Below offers another view as a filterable list, showing the hierarchy of features, parent, and child stories, and their current status, estimates, etc. giving a more comprehensive view.
This may seem like the antithesis of the “less is more” philosophy that many believe is the essence of Agile. However, the key to success in my experience, is a disciplined process to work through each story articulation level. Time-boxed meetings where only stories and scope that are ready for that phase are on the agenda. It’s a pull system, and it exposes bottlenecks in your pipeline quickly, rather than having such broad status labels that delays go unrecognized for too long. There’s nothing agile about grooming and estimating sessions that churn around and around because of inadequate story development. It all begins with the backlog.