The following is an extract from our book, Scrum: Novice to Ninja, written by M. David Green. Copies are sold in stores worldwide, or you can buy it in ebook form here.
Stories for the development team emerge from the product owner’s product backlog. A product backlog keeps track of all the input the product owner has about the direction of the product from the client, along with the research, experience testing, design, and engineering feedback the product owner has gathered.
Unlike stories for the sprint backlog, items for the product backlog don’t need to be structured in any particular way. That’s because their main purpose is to allow the product owner to keep track of all of the features that are needed. These product backlog items may be quite vague until they crystallize into a clear development story for the sprint backlog. Items in the product backlog should always reflect the product owner’s latest thinking about the long-term goals for the product, while the team is working on the specific features for the current increment.
Note: The Product Backlog is the Responsibility of the Product Owner
While a product owner may choose to share the entire product backlog with the team on a regular basis, the items here are the responsibility of the product owner. It may not be productive to keep reminding the team of items on the product backlog that haven’t been touched in a long time, because it will divert attention from the work necessary to complete the current increment.
While many product owners prefer to keep track of items in the product backlog as if they were going to become the final stories, there doesn’t have to be a one-to-one correspondence between items in the product backlog and stories that make it into the sprint backlog. Features and requirements that the product owner needs to track may turn into multiple stories, or several items may be combined to create one unified story of the appropriate size and scope for development.
For example, if the customer needs to add a payment system to a site, that may be a single story for the development team, or it may be multiple stories. There may be developer stories around creating the ability to accept payments through a service, and separate stories for accepting credit cards, checks, or even maintaining a token system so that purchases can be made using a virtual currency. It might be possible to develop each one of these independently, and launch the system with just one. Whichever one goes out first may need to carry the weight of implementing some core functionality that all the others will share.
Many product owners find it convenient to track the state of items in the product backlog using a staged process, whereby the item moves from ideation through design through engineering validation, until it’s ready to be phrased as a sprint backlog story and added to an upcoming sprint. Product owners should have a clear sense of what it takes to move an item from each of the states to the next, and that should be documented so it’ll be consistent for each story.
Warning: Don’t Write Stories Until They Are Ready to Be Worked On
It’s usually a mistake for a product owner to create development stories for items in the product backlog too long before they’re ready to be incorporated into a particular sprint. Items in the product backlog should remain vague enough and flexible enough that they can adapt to changes that emerge out of the iterative agile process of scrum. Product backlog items not worked on for weeks or months can easily become stale, and product owners can easily forget the context they had when writing the story if it isn’t worked on soon after it’s written. Writing stories in detail too early can often be a waste of the product owner’s time, and can lock the team into work that may not be what’s currently needed.
M. David GreenI've worked as a Web Engineer, Writer, Communications Manager, and Marketing Director at companies such as Apple, Salon.com, StumbleUpon, and Moovweb. My research into the Social Science of Telecommunications at UC Berkeley, and while earning MBA in Organizational Behavior, showed me that the human instinct to network is vital enough to thrive in any medium that allows one person to connect to another.
