Start at the beginning – product backlog
A product backlog is an ordered list of features or work to be implemented in a product. It could be infinite in length; that is, there could always be new requirements for a product. The product owner is an actual customer or an internal representation thereof (think of an iPad product owner representing many millions of users), maintains, updates, administers, and ranks the product backlog. Based on market research, a product vision statement, industry analytics, technical innovations, or simply ideas to test, the product backlog represents the product owner's most valuable ideas and features for a product.
Note
Once the team has selected, planned, and committed product backlog items to a sprint, the product owner cannot make any changes to those items. However, the product owner is given free reign to change the priority, requirements, and even remove any product backlog item that hasn't been committed and planned in a sprint. This simple game rule drives the product owner into a routine behavior of just-in-time preparedness: the product owner must rank and prepare detail for the most important product backlog items for the next sprint planning meeting. Likewise, the product owner should prioritize and prepare a set of features desired for a release in anticipation of that release's planning discussion.
Product backlogs are very useful for managing change because work that hasn't started can easily be re-ordered (tuned) to the market needs at any given point in time. If the team needs to react to an emergency competitor situation, the product owner can defer any not-started items to make way for the features to meet the competitive demand in the very next sprint. Since we know that market needs will change, it's in the product owner's best interest to put more planning effort and detail into the most important items the team will need to implement next. In the following figure, the product backlog is depicted as the basis for both long and short-term planning. The product backlog facilitates both levels of planning; that is, product backlog can be quickly and easily re-ordered for long-term forecasting, while in sprint planning, the highest priority backlog items will be planned with utmost detail (tasks, hours, owners, and so forth) because they are ready to be implemented at that time. The leanest implementation of a product backlog is to pull the top item from the backlog, finish it, release to production, followed by the next item, and so on, with no planning other than for one item at a time. This scenario is actually a reality for some companies, as we'll discuss in Chapter 11, Scrum and the Future. However, most teams at most companies engage in both long-term and short-term planning activities and use the product backlog as the main input.
Focus product backlogs on users and values
Product backlogs should be written for and releases should be planned around the product or features, not the components of a system. "The user can view a list of products on the main page" is a user-facing product backlog item, while "update the CSS to persist product header fonts" is not. Looking at a plan from the product perspective in user language helps the product owner bind release plans to market rhythms. In many cases, an even higher level of planning called a product roadmap will precede a release plan (see Chapter 6, The Criticality of Real-time Information, for more about roadmaps). Product backlogs, roadmaps, and release plans enable product owners and teams to see the whole; a lean concept that reminds us to step back and look at the big picture from time to time, not just the day-to-day details. In the following example, which product backlog do you think the product owner would have an easier time explaining to other business stakeholders? From which do you think it would be easier for the product owner to understand status? Which better enables the product owner to see the whole?
Product Backlog A is expressed as the best. Visualizing plans in terms of user value allows the product owner to move things around, de-prioritize scope, and negotiate the depth of feature delivery. Additionally, tracking status this way, along the lines of user value, helps him immediately realize when he may have a product increment for release (in this case probably after item number 4 has been implemented). He could also do this for Product Backlog B, but because the items are expressed as lower-level technical to-dos, the product owner would likely have to call a meeting or two to understand how all of these items map back to units of value that can be delivered. In fact, the items in Product Backlog B are better suited as sprint backlog items, tracked day-to-day by the team, that all together enable features to be implemented. We will explore this in greater detail in Chapter 3, Sprint Planning – Fine-tune the Sprint Commitment and Chapter 6, The Criticality of Real-time Information. As a ScrumMaster, you must ensure that your product owner and team understand the importance of expressing and tracking product backlog items as user value.
You may hear people refer to product backlog items by different names; legacy Scrum calls them generic product backlog items (PBIs), while teams may refer to them as features, user stories, and/or requirements in daily practice. Keep in mind that it really doesn't matter what they're called as long as they are written in a language that everyone understands. Since the product backlog enables both long and short-term planning discussions, we should try to use user or business language whenever possible
Product backlogs should have, at minimum, three columns of information: rank/order, a description, and an estimate (or cost). However, I have seen and worked with all varieties of backlogs, even one that spanned 17 columns and was accessed by as many as nine people at once (this was a huge program with seven teams, multiple area product owner proxies, one product owner, and several ScrumMasters). Many product owners choose to maintain their product backlogs in low-tech ways: on sticky notes (posted on the wall along with important information like a product vision statement), wireframes, page mockups, and so on.
Remember, the product backlog is both a planning and a communication tool at which many different people with different skills and responsibilities will look!
Engage the team early
Make sure that the product owner engages the development team early in product backlog planning. Each team member has his or her own skills, experiences, and ways of thinking about the product. Given an opportunity to brainstorm with the product owner and the rest of the team, team members can express new and innovative ideas, things that the product owner couldn't have thought of by himself. Some technical teams have been able to greatly influence the product's direction given a chance to participate in product backlog brainstorming very early in the product's development!
Paper prototyping is one of my favorite tools to help teams brainstorm products and product backlogs. In a paper prototyping session, the product owner and team work together to mock up the user interface, underlying components, and model system interactions—using paper! This is an excellent way to collaborate and get a feel for how the user will use the system; additionally, it provides a mechanism for the team and product owner to see if they missed any critical user stories, as well as facilitates the creation of some early acceptance criteria. Of course, a team can use paper prototyping for any type of system; modeling component interactions this way helps the team think through and gain a common understanding of the system's architecture. I use UXPin's (http://uxpin.com/web-kit.html) web and mobile paper prototyping kits in the classroom and coaching sessions; every team who has tried them loves them! The paper prototyping session brings value to a team in the form of product envisioning, collaboration, teamwork, shared understanding, and the creation of product backlog items.
I've stumbled across many sad mistranslations of Agile in the field; one is that only the product owner can add items to a product backlog. Please consider a better practice: anybody should be able to add an item to the product backlog. A product will certainly benefit if the product owner allows contributions of ideas by others, but keep in mind that in order to prevent a chaotic and stressful situation, the product owner is solely in charge of prioritizing—or more accurately, ordering—the items. Could you imagine how crazy life would be if 10 people were contributing to the backlog and fighting about priority every day?
Prioritization can be useful for other things
The following screenshot is an example of a project portfolio backlog created in Excel in December of 2012. The purpose of this list was to collect, in one place, all the 2013 project ideas from various product owners and prioritize them based on corporate objectives. The list is very high level and represents a mash-up of product launches, performance optimizations, and technical infrastructure projects. You may also notice that there are different requestors for each of the items (Dev, PO, QA). I like this example because it shows that the backlog concept is not only useful for prioritizing features within one product or release but also useful to plan a portfolio of projects based on organizational strategy. This list required several meetings with various product owners and department heads to work through, but it was the first time that they put all of their work into one list and ranked it, making all the work visible. There were some very tense moments during these meetings as some product owners realized that their ideas might not get much budget in the early part of 2013.
The CEO acted as uber-product owner in this meeting and ultimately decided where the money would go. I liked the organization and simplicity of this list; note how the product management team divided the backlog into months of work (December, January, and so on) in a spreadsheet. It's easy to group rows under month headings (or whatever headings you like) in order to collapse/expand parts of the backlog; it was really easy in the prioritization meetings for the ScrumMaster to click around to expand/collapse certain months in order to focus everyone's view. This view eventually acted as a landing page from which product owners could drill down into specific product backlogs; notice the link for the New Product Blog item—the product owner could click on the link in order to go to the specific product backlog of features contained in a separate worksheet for only that project. This allowed the group to drill down to supporting detail and quickly click back to the landing page to support different levels of conversation in the prioritization meetings. Google Sheets works really well for product backlog organization and enables real-time collaboration with many users at once. There are many Agile tools on the market that help product owners maintain their product and project portfolio backlogs (see www.userstories.com for a list of tools and ratings).
