It seems like most of the Scrum articles and books that I’ve read as well as the lectures I’ve heard have very little to say about the process of creating the items on the backlog. How should a team on a medium or large project (i.e. more than a few team members) go about creating and detailing the items on the backlog? When and how should the ideation and story writing occur? Who should be involved and when? When should team members (other than the product owner, of course) join the process? How much of the team is needed?
Note that I am not asking about how a small group would create a user story or other backlog item from ideas. I’m asking more about when and how this ideation and story writing should occur and who should be involved. How can we be more Agile in the ideating/story writing stages?
8
Creation of the backlog is defined as an input to scrum. A few things are said about what it should look like, but not about how to get there. The most agile way is really to figure out what works for your company.
Our company starts out with a giant prioritized list made by product management with input from the product owners. This list is at an extremely high level, like an entire new product or a major feature, a few dozen user stories worth of work spread across two or three scrum teams. They prioritize those features based on what will make us the most money the soonest, or keep us from losing money.
They occasionally ask the scrum teams for a very rough estimate, with a resolution of tens of weeks, on how long it will take us. If that estimate is large, they will reduce the scope until it meets customer needs, or decide to do something else first.
Once every ten weeks, they assign out the highest priority epics to the scrum teams. The teams break them down to the user story level, assign story points, coordinate dependencies on other teams, and put the stories in order. At that point we have a “real” backlog per team. Management reviews that backlog to make sure the smaller milestones are appropriate, that we are meeting the business needs, and that the estimates work with their larger plan. Usually they accept the judgement of the individual teams at that point. Sometimes, the detailed backlog creation reveals problems that management has to rethink at the higher levels.
There are also non big picture items on our backlog that the scrum teams create themselves based on only general ongoing guidance from management. These are things like bugs or support issues that come up, tools we think would help improve productivity, or refactoring. The rule on our scrum team is anyone can create a user story for any reason at any time, but the product owner decides when it is high enough priority to be pulled into a sprint.
We based our approach on Dean Leffingwell’s Scaling Software Agility: Best Practices for Large Enterprises. He actually came to our company and trained us when we first started agile, but in true agile form, we’ve evolved our processes to work better for our company, and continue to do so.
2