12 Q&A on Remote Product Backlog Refinement
#1. What is the Product Backlog?
The product backlog is the collection of all the work that should be done for a specific product. The backlog is made of: user stories (new functionalities), spikes, maintenance.
The product backlog is always ordered based on the items that bring most of the business value on top and at the bottom, the things that bring less value.
#2. What is the goal of the Product Backlog Refinement (PBR)?
Estimate the product backlog, starting from the top of the backlog.
#3. Who attends the PBR?
The scrum team and subject matter experts.
#4. Who leads the product backlog refinement?
The scrum master or product owner facilitates.
#5. Is the PBR a meeting?
Being in an office, every time we meet someone in a meeting room, we have the feeling that meeting someone is about someone presents and the other listens. Doing remote refinement is the perfect time to realize this is NOT necessary a meeting. Because we meet colleagues to work together or clarify specific topics. That is creating a new way of working — meeting colleagues to work in a virtual meeting room.
#6. What tools can we use to work together on a PBR workshop?
- Video conference tool. You have a wide choice between Zoom(my favorite because of the low), Skype, Teams, Google Hangouts, Whereby, and many others.
- A good microphone. It is imperative to be able to hear
- Headphones. You can also use speakers, but most of the time it creates an eco
- Drawing tools (e.g., Draw.io, Canva, paint)
- Whiteboard (most of the video conference tools already have a whiteboard feature included — just make sure you save the image).
- Annotation tools — Zoom has an annotation function included
- Mindmap tools (e.g., Coggle.it, LucidChart, MindMeister)
- Story points estimation tools. (PlanIT Poker)
#7. When should you do PBR?
Every sprint for 1–2 hours.
#8. How to prepare for PBR?
For the product backlog refinement to be advantageous, the PO must prepare ahead of the user stories: description and acceptance criteria. Feel free to add additional information, such as data samples, mock-ups, images, etc.
#9. What is the agenda of a “classical” PBR?
- The Product Owner presents to the team the top user stories on the product backlog that aren’t estimated yet
- The tribe discusses with the product owner the details of the user stories one by one. The discussions should include: are the description and acceptance criteria clear, can it be estimated, should it be reduced or increased, dependencies that the team has to do the user story.
- The team estimates the user stories or identifies spikes
- The scrum master summarises all the action that still requires external input or work.
#10. Do we put everything in the backlog, and then we see if we get them done?
NO. One of the qualities of a Product Owner is to know to say NO to the feedback received and implement only the functionalities that match the Product Vision.
#11. How far in advance should we do the PBR for a user story?
The best practice is 2–3 sprints in advance minimum and maximum. If we prepare it too late, we miss the opportunity to identify on time the dependencies. If we make it also in advance, we risk that the user story to don’t be relevant anymore or to change. In those circumstances, the scrum team wastes time and effort spent in preparing and estimating the user story. Also, keep in consideration that a user story refined six months before; even if it still valid, the product owner will need to remind the details to the team. That is also a waste of time and effort.
#12. Bonus: PBR Meeting Alternatives that work:
- Team members write user stories. Traditionally, it is the Product Owner’s job to create user stories. But as the teams become more multi-disciplinary, teams learn to master the Agile techniques, the Product Owners’ role becomes more complex, they can trust the writing of the user stories to the scrum team. But the PO remains responsible for the product backlog.
- Work together alone — the team members split into groups or work individually on specific user stories for a fixed period. When the timebox is over, the team members come together, and everyone shares with the others their work. Collectively they agree on the final version of the user story and estimate it. It is a method that works great remotely because there is no temptation to discuss other subjects inside the distributed team members.
- Prototype, design, configure, develop during the PBR. The PBR is not just a meeting; the goal is to estimate the backlog. The team can find new methods they can use to bring clarity to the upcoming user stories. I highly encourage the teams I work with to get their hands on the real work, so they get a better understanding of the work to do. Resting at the surface is instead a waste of time in yet another meeting.
