Test 1

During sprints, Scrum teams work on the items in their sprint backlog. Since the purpose of the team should be to deliver value, their focus should be on completion of the items they have committed to.

However, there is more to think about than only the current sprint. Teams are expected to prepare the product backlog items that they will work on in later sprints as well.

Refinement is time spent during the current sprint discussing and elaborating product backlog items so that they are ready for future sprints. The importance of refinement is underestimated by many teams, which is a pity since it has some nice advantages.

Good refinement: 

• Leads to better solutions, since it is the product of many smart minds.
• Reduces the number of surprises during the sprint, since the team thought about risks and dependencies in advance.
• Provides accurate information about the technical complexity, which can be used to plan and prioritize the product backlog.
• Leads to better estimations and thus better predictability.
• Leads to better quality and efficiency, since the team can divide tasks in such a way that everyone contributes with their specialized knowledge.
• Ensures that the team delivers the highest value first.
• Gives stakeholders time to define and discuss their needs with their supporters, such as operational employees.
• Increases flexibility, because changes in priority have no impact on team effectiveness.
• Results in commitment by the whole team, since everyone is involved the definition of the solution.

Unfortunately, many teams do not unlock the full potential of refinement.

Not only is the time spent on refinement often limited, but many of the refinement meetings I join are inefficient.

I meet teams that spend half the meeting watching the product owner entering the new backlog items in the workflow system. Although they estimate the user stories afterward, little time is left to discuss the best solution and risks that need to be avoided.

Often, user stories are owned by one developer who is regarded as the expert, and other team members are not really involved and focus on their own user stories instead. Again, little time is spent on exchanging ideas in order to come up with a better solution.