Parkton Punk: Hi all. When does your team do refinement? Do you schedule separate sessions for this during the sprint (for the next sprint)? Do you do this as part of another ceremony (sprint retrospective?) A combo of both? Something different? I’m talking less about perhaps correcting/refining the order of the product backlog and more about discussion of new stories the team has not seen previously. Thanks!
My recommendation is to consider backlog refinement a continuous process that occurs at any time. If a refinement is a consequence of an action originated by the Team or by the Product Owner, it’s not relevant at all and depends on the concrete framework a team is using and the common agreed understanding of the responsibilities. My only recommendation is to do the refinement AT ANY TIME you identify something to be refined. The sooner, the better.
Refining just once per Sprint (doesn’t matter when) doesn’t work and has been for me a source of many conflicts.
Of course, remember than new stories only can be added if actually come from a need expressed by business stakeholders without conditioning them or assuming “they will love it, but don’t know yet!”
Only exception, of course, are non functional aspects that are derived from the Sprint backlog, but also as the result of the continuous improvement culture a Team should always have.
They are many times named generically “spikes”. Doesn’t matter the name as far as nobody use them for feeding his personal curiosity but without a clear outcome agreed by the overall team.
My 2 cents
@jordi.borja makes a great point! I tend to see a progression kinda like this on teams
Starting point - new team forms and doesn’t have a scheduled refinement session…often this results in stories being introduced for the first time in sprint planning…they require some discussion, this tends to get rushed or sprint planning takes forever. At some point the team brings up long meetings in the retro and someone has an idea to introduce stories earlier
Some improvement - Team decides to schedule a standing meeting for refinement, this is an improvement over step 1. Some teams decide this is good enough and working well so they hang out here, other teams realize batching these discussions into one or two hours a week creates some challenges (why can’t we just talk about it when it comes up) and they decide to bring it up in a retro and go to a flow state
Flow state - These teams have started to work really well together and are able to have a steady exposure to new stories negating the need for a standing meeting…often they may decide to transition from scrum to more of a lean kanban model as well further increasing their ability to flow and reduce batch size even more.
With all that said I’m currently working on a brand new team and could probably benefit from a standing meeting…we’ve got a long way to go before we’re flowing!