The Product Backlog and How to Manage Your Way Out

The Product Backlog contains a prioritized list of the Features we wish to build. The Product Owner works with the Customer to develop and prioritize the backlog.

Features are broken into User Stories of various sizes. A user story is small enough to be completed in a single Sprint.
The Product Owner must work to define the Business Value of the features and user stories. This is often done with an eye toward the reduced cost or increased revenue the story generates. The size of the user story is also a consideration in backlog priority. A feature with a small size and a large business value are typically high in priority.
It is not always simple to assign priority. When this is the case, we need to use a more sophisticated technique to prioritize the backlog. This could be Weighted Shortest Job First (WSJF) , Kano Analysis, Theme-Screening, Theme-Scoring or Relative Weighting.

Release Before the Product is Complete

We should work to identify a set of Release Candidates. A release candidate is a set of features that delivers an operational product to our Customer. We want to ship as soon as possible, even before the product is complete.
It is up to the Product Owner and Customer to identify the Release Schedule. A common practice is to deliver two or three sprints of user stories followed by a hardening sprint that results in a release candidate.
The amount of work the team can deliver is based on their velocity and capacity.
The Scaled Agile Framework uses the term Potentially Shippable Increment or PSI.
This gives us a cadence of quarterly releases. This is a very good thing. The customer learns to expect valuable software every three months.

It is all About Customer Value and Regular, Flexible Delivery

A number of important benefits arise from this agile approach. They are:

• The Product Owner and Customer set the priority of the Features they want.
• Features are delivered and completed in short sprints so progress is obvious.
• Before each sprint, the Product Owner has an opportunity to change her mind and modify the schedule.
• We are never more than one sprint (2 weeks) away from delivering new features which, in turn, gives us frequent opportunities  to change and adapt.
• We are never more than one release (three months) away from a release of software to our customer.

This builds confidence in the product with our customers and in the delivery team with senior management. This cadence can continue forever or until we decide to stop.

Learn More

• ScaledAgileFramework.com
• Mike Cohn (Blog)
• Release Planning Guide (Rally Software)

Books

• Agile Estimating Planning (Mike Cohn)
• Agile Software Requirements (Dean Leffingwell)