Refinement, also known as "grooming," is one area where the Scrum framework has intentionally left little guidance to go by. According to the Scrum Guide
, refinement " . . . is an ongoing process in which the product owner and the Development team collaborate on the details of product backlog items. The Scrum team decides how and when refinement is done. Refinement usually consumes no more than 10 percent of the capacity of the Development team." The idea is to devise your own refinement session based on the team's appetite for it.
I have worked with many teams and almost all of them start out by saying, "There are too many meetings in Scrum," and in the same breath they say, "The quality of our stories isn't good enough for planning." Because these two statements come in pairs, my job gets a little easier, i.e., my response is usually, "If you don't spend enough time refining, you are likely to spend more time in planning, ultimately affecting your estimates and commitment or forecast."
I usually see mature teams run refinement sessions by sending the Three Amigos
to save other team members' time. This means that the team is productive and working on delivery, even during refinement sessions (I am not implying that the refinement session is a nonproductive activity!). Also, these teams often feel comfortable with the idea of having a number of short refinement sessions. I have found it useful to have storyboxed and timeboxed (whichever is earlier) refinement sessions. Almost all of the teams have liked this idea, whereby the team decides on the number of stories they want to discuss and the time each session will last. This means that teams get a sense of control, and they also get their time back if the number of stories we planned to discuss during the session are refined quickly.
There are other benefits to having short refinement sessions: They give our product owners, business analysts, and Development teams the opportunity to seek clarifications between sessions. They also help keep the team focused on a couple of stories rather than looking at the whole sprint. Keeping the sessions short means that you can have their full attention for 15 to 30 minutes.
I have tried different time lengths and timings for the refinement sessions, from 15 to 30 minutes and from straight after the Daily Scrum to a session just after lunch. The session length that has successfully worked for me and teams I've worked with is anywhere between 15 and 30 minutes maximum, scheduled just before lunch. There is something about the timing before lunch that always makes the meeting productive and helps us finish on time.
How much refinement is enough? This is a very subjective question and has no right or wrong answer. Some teams like to go into detail about implementation and, if possible, also drill down to the code level. In these cases, I usually step in as a facilitator and remind them that this session is primarily to understand the business requirements, ask questions about these requirements, and raise any assumptions they will be making so that product owners can validate them. This is also a session in which a team can assess the size of the story in terms of whether it's suitable to make it into the sprint "as-is." The team can also determine whether they should revisit the story and slice it in such a way that they are able to deliver business value, yet it's small enough to be accommodated within the sprint.