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?

| improve this question | | | | |
  • 3
    This article seems pretty clear. What are you having difficulty with, specifically? As currently written, your question is too broad to be answerable in a Q&A format, and I have the feeling that you may be overthinking it. – Robert Harvey Feb 8 '13 at 16:26
  • I'm having difficulty figuring out when story creating/writing should occur, and who should be involved. Should it happen all in sprint planning? In numerous backlog meetings beforehand? Should the whole team be there, or one or two key developers? When should the developers be first introduced to the stories? All the article you provided says is "The product owner shows up at the sprint planning meeting with the prioritized agile product backlog." How does the backlog get that way in the first place? What are some common ways that teams do this? – Patrick Szalapski Feb 8 '13 at 20:37
  • If this is the wrong site for this question, can anyone suggest another site that I could ask it on? – Patrick Szalapski Feb 8 '13 at 20:37
  • I take it Karl's answer didn't do it for you. – Robert Harvey Feb 8 '13 at 20:40
  • 1
    Are you expecting others to answer in a materially different way? Good questions should be definitively answerable, not invite multiple subjective opinions. We're not a discussion forum. – Robert Harvey Feb 8 '13 at 20:46

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.

| improve this answer | | | | |
  • This is exactly the kind of answer I was hoping for--thanks for getting it in in time. – Patrick Szalapski Feb 8 '13 at 20:45

Not the answer you're looking for? Browse other questions tagged or ask your own question.