There is not much written about Product Backlog refinement in the Scrum Guide, where you read that refinement is “is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.” Why refinement isn’t an event?

Refinement isn’t an event, as it goes on and on

The Product Backlog is a living Scrum artifact, meaning it’s never complete and it’s continuously <refined>. One of the reasons refinement is not an event is because it’s an “ongoing activity”, kind of process, while events are occurrences that indicate completion. Events start and finish. Refinement goes on and on. During the Sprint the Product Backlog Items require refining. There are no hard-and-fast rules on how to run a refinement session, neither are you told when to do that. Since it’s a continuous activity, it can be done any time. You don’t need a meeting for that. You might as well do it while having a chat.

What is the purpose of refinement?

All the time, as it’s “an ongoing activity”. Some claim refinement should be carried out before the Sprint planning initiating next Sprint. That way, it doesn’t concern the PBI’s selected for the Sprint Backlog; rather, it’s for future Items. Neverthless, it needs to be pointed out that during the Sprint planning the discussion the developers have with the Product Owner as to what PBI’s to pull into a Sprint is also refinement. The key of the refinement is to define the pieces of work and make them more clearer.

Refinement isn’t an event, so it has no timebox

All Scrum Events are timeboxed, meaning they need to occu by certain period of time. Refined Items are those deemed Ready, meaning they can be pulled into a Sprint. Pulling is the lean thing in Scrum, as no-one is pushing anything under the team. If you wish to comment on refinement, feel free to join a discussion here.