Let’s start with the rules. _"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._1”
On day one of a project, I recommend the Product Owner and Scrum team are aligned on expectations and the minimum amount of time for refinement during the sprint. Personally, I specifically outline the following in our refinement meetings...
“When we set a Product Backlog Item to the state of Approved, that means if it is the next highest priority item the team would be comfortable taking it into planning, tasking it out, and implementing that feature. There are no outstanding questions, no known impediments, it has proper Acceptance Criteria and an associated Effort. The goal of our refinement meetings is to get the next 2 sprints worth of Product Backlog Items to the state of ‘Approved’.” In essence, I create a Definition Of Approved and a contract with the Development Team in the same mindset of Definition of Ready.
Refinement should be collaborative. Don’t be afraid to get up, draw on post it notes and whiteboard workflows about how screens will be laid out. I find that the most productive refinement sessions involve everyone on the team sharing their ideas openly. Then as a team we are updating acceptance criteria with scenarios we uncovered. We’re coming to alignment on Why we need the feature, What it is, and at a high level talking about How we’ll likely implement it. Team members should feel comfortable asking questions or asking the product owner to be more detailed in their acceptance criteria.
As the discussion on each feature comes to a close I end with the same question; “Can we effort this?” If the answer is No, then the next question is why not? These questions are the additional refinement that is necessary. Often the answer is yes with assumptions A, B and C. Add those assumptions to the Product Backlog Item! They are risks and may need additional refinement.
Similar to the previous question the last one I ask is “Can we set this to Approved?”. We apply the same rules as before. If the answer is No, ask why not? The unknowns are the remaining refinement we have to do.
Taking a step back to the “Why Not” questions above. Sometimes these are answers the Product Owner takes to the business like validating workflow or edge case scenarios. Just as likely the team needs time to investigate or research an approach before knowing it is the correct path. In both scenarios this is continued refinement which should happen throughout the sprint and duration of the project. Don’t be intimidated into thinking the confines of a meeting are the only place refinement happens.