I've recently been involved with several Scrum Teams that are struggling to have the right level of detail in their Product Backlog items. Some symptoms: difficulty during Sprint Planning sessions, a massive or very small Product Backlog, or a lack of understanding during a Sprint. All of the teams I spoke with had refinement activities in place. It is important to note that Product Backlog refinement is not a formal event in Scrum. It is an important activity; however, the implementation may vary drastically by team.
The Scrum Guide defines Product Backlog refinement as:
"Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion."
The Scrum Guide then states that:
"Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning"
It is a general recommendation to have one to two Sprints worth of "Ready" Product Backlog items in the Product Backlog. Does this seem like a far-fetched recommendation in your world?
Here are a few tips that may help to get you there:
Make it a formal event (or not)
From my experience, there is no single right way to incorporate Product Backlog refinement into a Sprint. You may hold it daily, weekly, or once a Sprint. It doesn't matter as long as the refining is accomplished. As mentioned, the Scrum Guide states that it usually consumes no more than 10% of the capacity of the Development Team during a Sprint.
Product Owners, it is perfectly acceptable to delegate and ask a Development Team to refine items informally and when needed. I find it useful as a Product Owner to coordinate these activities with the Scrum Master who is often facilitating for the Development Team. You may also choose to make it a formal event that occurs on a cadence within your Sprint. Inspect and adapt during Sprint Retrospectives and find out what works best for your Scrum Team.
Involve only who needs to be involved
There is an inclination that in self-organizing Development Teams everybody needs to be involved in everything. I don't find this to be true in Product Backlog refinement. In general, if it feels like a waste of time involving everybody then simply don't. The Scrum Master may facilitate conversations with the Development Team to determine who should attend a given refinement session. However, it is true that the Development Team should collectively have some degree of information on what is coming up next. Trust them to talk to each other.
I feel it is important to mention that as a Product Owner, one thing I am conscious of is trying to find time with a Development Team(s) to get collective buy-in for the plan I am laying out. I also want to get their opinion on how things should be ordered or if they have any ideas for new Product Backlog Items. You may use a more formal event for this (or not).
Define what "Ready" means to your Scrum Team
You may introduce a complimentary Scrum practice called the definition of "Ready". The definition of "Ready" is a short checklist of things that a Scrum Team should do before a Product Backlog Item will be brought into a Sprint. It is a helper to set some boundaries around what a Development Team might need to get a Product Backlog item "Done".
Be careful that this does not become a strict contract between the Development Team and the Product Owner. The Development Team serves the Product Owner. If the Product Owner comes to Sprint Planning with a very high-value Product Backlog Item that doesn't meet the "Ready" criteria it shouldn't matter. The value of the work does not change.
Estimate when you have to
Estimates serve two purposes: for the Development Team during Sprint Planning to aid in forecasting how much to bring into a Sprint; and for the Product Owner to comprise or maintain a release plan. If neither of these are concerns at the moment, then estimate when you have to, not just because you feel obligated. The later you estimate the more accurate your estimate will be. One could argue an accurate estimate is impossible and a waste of time when working in a complex profession like software development, but we will save that discussion for another day.
Don't get too far ahead
If you are refining Product Backlog Items that will be worked on by the Development Team several months in advance, stop. It's a waste of your time. Requirements are often one of the most unstable aspects of software development. It is very difficult to accurately capture a customer requirement regardless of the format you are using or the amount of effort you put into it.
A Product Backlog with stale items means you wasted time creating requirements that are no longer relevant. Stick with one to two Sprints worth of "Ready" items on the Product Backlog. Likewise, don't assume that every aspect of a Product Backlog item needs to be explicitly defined. Allow for some room for conversations and creativity about the implementation during a Sprint.
Conclusion
There is no single way to define Product Backlog refinement generically in Scrum. It is an excellent topic to discuss in a Sprint Retrospective so that you are inspecting and adapting the team's approach. Try making it a formal event (or not), involve only who needs to be involved, define what "Ready" means to your Scrum Team, estimate when you have to and try not to get too far ahead.
Reference: Scrum Guide