PLAY Introduction
A product backlog is a prioritized list of work for the development team that is derived from the roadmap and its requirements. The most important items are shown at the top of the product backlog so the team knows what to deliver first. This play will help you deliver a product backlog that works!
PEOPLE
2-10 depending on the size of the team. If it becomes larger than 10 people consider breaking out into smaller groups.
TIME
30-60 Minutes. No one wants to be in a meeting longer than needed. Try to keep it short and sweet.
NINJA LEVEL
Novice to Master. Anyone can develop a great product backlog!
PREP WORK
PEOPLE
This is key to successful meetings. Make sure all key stakeholders are on the invite, the decision makers and those funding the product. You need their buy-in from the start!
PLACE
Virtually or in-person it is critical that everyone has face-time with each other. So make sure that if attending virtually that everyone can connect in video chat. You will also need to share ideas, so a whiteboard is important and a space that fosters creativity and innovation.
THE PLAY
All of our plays are five steps or less! However, you may need to run multiple plays to get the most out of this one. Don’t worry – you can do it! Learn the play, rehearse it regularly, apply it in the field and debrief on the outcomes. If it worked well, use it again; if it didn’t, find out why. Are there new factors in the system you need to consider, or do you just need to keep practicing? If you need help or have questions on this play, contact us!
01
SET THE STAGE
Who are the players?
Every winning team knows which players to have on the field and what talent you need on the ready. To successfully deploy this play you will need the following roster:
Meeting Facilitator/Scrum Master: Likely this is you! But you don’t have to do it alone, ask a friend (think of it like a football team that has a coach for different parts of the team). Skills needed:
- Keep the team focused on the goal!
- Foster a positive and creative space for all
- Organized and prepared to run play
Product Manager: A product manager is a professional role that is responsible for the development of products for an organization, known as the practice of product management. Product managers own the business strategy behind a product, specify its functional requirements, and generally manages the launch of features. Skills needed:
- Ability to balance business and user needs
- Attention to detail
- Curiosity to explore new ideas
- Ability to deliver factual data in-time
- Empathy for customers
- Ability to build strong relationships with other teams
- Understanding of necessary data structures
- Informed about the technical implications of the platforms being used
- Ability to tailor communications to different stakeholders
Product/System/Business Unit Owners: These are decision makers. They can make the call on what changes will happen or authorize a strategy. Skills needed:
- Change agent. Supportive and enthusiastic about improvements.
- Supportive of the team and SMEs!
- Committed and engaged in the product.
Subject Matter Experts (SMEs): A SME (pronounced S-Mee) is critical for this play. They will help drive the team to a shared understanding of what is needed to win. Skills needed:
- Specific domain knowledge, narrow and deep rather than broad and shallow.
- Communication and team collaboration. They must be able to share with others the knowledge they have on a particular subject.
Get the field ready!
Schedule the meeting in advance. Don’t wait until the last minute to schedule the meeting. You want people to be excited about it but not so last minute that they have no time to prepare.
Include an agenda. Set expectations – this will help keep your meeting on track. Include schedule and any prep work needed. Also let them know if it is okay to invite others or not. Remember that if you have to many people in the meeting, it will be difficult to facilitate brainstorming sessions without breaking out into smaller groups.
Prep the room. Arrive early and get ready. If it is in a physical room, get whiteboards ready, enough chairs for everyone, water and snacks are always a hit! If virtually, a central location for notes, brainstorms and follow-up items. Test connectivity in the meeting room and make sure there is enough seats for all participants.
02
CORE ACTIVITIES
CREATING THE BACKLOG
To get started creating a product backlog, you will need a Product Roadmap. This is a strategic plan that offers a longer-term outlook for your product.
While your roadmap might include long-term goals for several releases, the product backlog should focus on listing work for the next release in greater detail. Future releases should be placed lower down and expressed in less detail. Then, take the information from the roadmap and translate that into tasks and work items.
TASKS AND WORK ITEMS
All work for a product is captured in the Product Backlog, regardless whether the work is performed as a ‘project’ or not. Work is often expressed in terms of requirements and often in Agile these are captured in User Stories. Run our Defining Requirements play to generate a list of stories for your backlog, if you haven’t already.
Agile and Scrum does not require that work items are in a user story format, all you need is a good list of items at the top of your backlog that can be worked on immediately, or in Scrum terms, is ‘sprintable’ (this isn’t an actual word but more of a concept).
What does it mean for a story (work item) to be sprintable? It means the dev team perceives that they can complete the story without needing further input from outside of their team. More specifically, for any questions team members may have about a story, the team has either 1) received an answer or 2) been given the autonomy to answer it on their own.
Easy enough, right? Yes, and the easiest way to find out is to ask the dev team. This can be done in a backlog grooming meeting and should occur regularly to ensure everyone agrees and is on the same page before the sprint begins.
BACKLOG GROOMING
You are looking to accomplish a few things through grooming sessions. First and foremost, you want to make sure tickets at the top of the backlog are fully fleshed out and ready to be put into the next sprint.
A story (work item) is ready when:
- It is completely groomed
- Acceptance criteria is written
- There are no open questions/impediments attached to it
- It has been placed in the backlog
- There are tasks assigned to it.
Week by week, tickets will become more defined, which may lead to additional tickets or supporting work. You also want to prioritize the remaining tickets, so the highest priority items get the most attention.
I also recommend using a timer for backlog refinement, especially at the beginning. Generally, one backlog item should be “refinable” within 10 minutes. Try it and see. If the item cannot be refined in 10 minutes, it usually means that either the item is too big and needs to be split, or, that you don’t have the right people in the room who are knowledgeable about the item.
If it starts to go in circles or people get the glazed over look, leverage the ELMO technique during backlog refinement. ELMO is an acronym for “Enough Let’s Move On” and it helps remind people to avoid boiling the ocean or rehashing the same thing over and over.
Recommended Reading
When asking people in product management about one thing they find difficult in their work, a typical answer is: “saying no”. Saying no effectively is not as easy as it seems and can’t be done in the same way all the time. In fact, saying no sometimes seems like an impossible thing to do. Saying no often as a product owner or product manager means you’re saying yes to the right things.
Want more information on how to facilitate great product backlog grooming sessions? See this article by Anthony Mersino.
03
TEAM HUDDLE
TEAM HUDDLETime to run the Team Huddle play. Ask the team the following questions and then take a vote. Keep follow-up questions to a minimum and capture any issues raised as an offline follow-up (and be sure to follow-up).
Understand the play?
The play was understood and I asked any questions in time!
I’m not sure I understand and I have some questions …
I did not understand the play or my part in it.
Did you get in the game?
Yes, I made my moves and was in the right place at the right time!
I’m not sure I understand what I was supposed to do …
I kept the bench warm and watched from the sidelines.
Ready for what’s next?
Yes, I know the game plan and ready to win!
I’m not sure what’s next or if I am involved …
No clue what’s next and would rather sit it out.
04
NEXT STEPS
Phew! The hard part is done! You might be tempted to go further and plan the next sprint – but don’t! Instead congratulate the team on a very successful and productive meeting!
Schedule the next meeting where the team will take the next set of work items into consideration. Set a regularly reoccurring meeting cadence so that the team stays engaged and is front of mind.
Publish your notes in a central repository that the team has access to immediately. Even better if it is someplace that the team can add comments or collaborate on. Keep the creative chat going!
05
IT’S A WRAP
You did it! Now just a few follow-up items:
- Reflect on the play. Ask yourself how it went? What could have gone better, what could have gone worse? In sports this is watching the game again to see any plays that could have been better. Update your playbook. Build feedback loops that help you see what’s working; what’s not; and how to continue to develop the playbook by learning, adapting and iterating constantly as situations change and new challenges arise.
- Contribute to the community of Playbook.Ninja. Sign-up for an account and receive updates on when new plays are added and help others by commenting on the plays with what worked or your experience.
Thank you for being a Playbook.Ninja
