What is all this stuff?
Can we take a look at the Product Backlog? Does this backlog contain a long list of prioritized “stuff to do”? Does this list include defects, functional tasks and/or feature requests? What else? Does this list include everything? Are there more items in the backlog than we can see in one glance? Have we determined the business value in this “stuff” as a basis for stack-ranking these Product Backlog items? Can we estimate this “stuff” in terms of relative complexity and help with prioritization? In reality do we have multiple lists for the product being worked on simultaneously? I would guess if the Backlog exhibits any of these qualities the product suffers accordingly. Does it suffer? Don’t worry, we can sort this out.

Coherence
For some, transforming lists in to a Product Backlog of this stature appears daunting. Enthusiasm to just get it done may ignite a desire to take it on all-at-once. Through the application of some workshops to shape and strengthen the backlog followed with check ups at regular intervals, the highest priority needs of the product should be well understood by all while team members remain friendly with each other.

Step-wise refinement
AKA Inspect and adapt. AKA kaizen. AKA iterate and increment. We can apply it as well to the effort of keeping the backlog in shape. Starting with what we have let’s sharpen it up a little, evaluate it against the running and tested features, step back and take a look at what we need and tune the backlog a little more. Take breaks to help keep the energy up, and the perspective fresh.

Who should we involve in this?
If possible, the whole team and the customer who will use the product and led by a single Product Owner. The team may be large, customers busy and the users many. Representatives from every role involved in definition, analysis and design come together to shape the backlog in these instances. Led by Product Management, common roles for the Product Ownership Team include Business Analysis, User Experience, Technical Publications, Software Engineering, Quality Assurance and Customer Support. The people involved should include those who can represent Product Ownership for the Scrum teams involved. The team should be broad enough to ensure a shared understanding by everyone of why we make what for whom. This team should be small enough to maintain consensus and get things done in a collaborative manner.

How important is it?
Everything captured in these lists are important, or should be removed. What critical needs should the system provide to the market, customers and users? Leaving some in vague terms is all right. What objectives do we satisfy and what outcomes are we looking for in a release? Write these up in a largely visible way for everyone to see.

How many items do we have?
If there are more than 3 or 4 Sprint’s worth of items on the backlog, we can walk through the backlog and prioritize based on the visible goals. Anything that can be easily agreed to as necessary calls attention to why they are valuable. It may necessitate adding to, or modifying the goals as well. Along with breaks keep sorting and look to see if about twenty percent, and/or enough for about three Sprints, of the items have bubbled to the top. Along with the visible objectives and outcomes, this will help ensure we concentrate the rest of our efforts on the things we need to work on now.

What do we have?
Let’s determine what types of “stuff” dwell in these lists of requirements. Could there be features, system specifications, use cases, tasks, defects, change requests and other errata? Does anything answer to the format of a User Story? Could it be considered a good one? Does the story have any acceptance criteria attached to it? At the end of these exercises, the backlog items should be identified by type. Characteristics of good User Stories have been discussed and examples are now identified. The teams start to have a better understanding of what is being created to fit the domain.

What’s it worth?
Starting with the first item, the team should discuss how this may fit in to a User Story. If there are items identified as User Stories, check for clarity what makes that the case and refine as necessary. The story may need some rephrasing, split if complex, or combined with others if not really valuable. Capture as acceptance tests the confirmation agreed upon as the scope and value of this user story.

Features and change requests are close to user stories. Once a couple of user stories have been discussed these are easy to reformat to fit the template. If it is not a user story, it could be part of acceptance criteria of one. Use cases and tasks are likely candidates. Otherwise, it may be a non-functional requirement or a constraint of the system. These are likely found within the tasks listed. Defects encountered should have the actual and expected outcomes recorded. This helps make sure they are not really change requests. If they are enhancement or change requests, it is easy to rewrite as User Stories.

What else needs to happen?
Now that the backlog format contains User Stories we can estimate relative complexity with Planning Poker. Look for the themes that the User Stories belong to, and identify Epics and Spikes. Keep the non-functional system constraints visible. We can turn it in to a Backlog Map, AKA Story Wall, to help prioritize and discern viable releases. Mid-Sprint pre-planning meetings will keep the backlog in shape, ensuring there remains 3-4 Sprints’ worth of Stories and well-understood acceptance criteria.

Is that all?
Keeping the backlog in shape with well-sized User Stories and acceptance criteria is an ongoing process continuing for the life of the Product using routine collaboration sessions, design workshops and Planning Poker. This is the input in to the system and Sprints will only go as well as the shape of the Product Backlog.