6 Challenges In Running Effective Refinement Sessions With New Teams

Do you know what can make Refinement sessions more difficult than they already are? Running effective Refinement sessions with new teams formed by new people working on a new product. But cheer up, there’s nothing you can’t handle.  

The way we run Refinements is different depending on how mature a team is. If you are just building a new team, you might try doing things the same as with a team that has been working together for a long time. 

And you can get frustrated when you don’t have the same results. Don’t worry, you most likely just need a fresh approach.

So here’s a list of 6 of the challenges I’ve encountered the most when I worked with new teams. Plus some tips about running effective Refinement sessions with new teams. They are meant to help you overcome these challenges. If you want to read more about the Refinement session, check out this post.

1. Build strong communication between the Developers and the Product Owner

Refinement sessions are difficult when a team is just forming. And if the team also has to work on a new product, it gets even more complicated. 

The Refinement event encourages communication and collaboration. At the same time, it strengthens the sense of responsibility of the entire team when implementing a User Story. That’s because they created it together with the PO.

Where is the lack of communication coming from?

• When we work in distributed teams and we only see each other virtually, it is very easy to be distracted by other activities. Especially when your camera is off, sometimes we don’t pay attention to what is being said;
• Many teams comprise members from different countries, and language can be a factor influencing communication problems;
• Some may be afraid to ask questions for fear of saying something wrong;

What happens when communication is missing?

• The team does not ask enough questions nor collaborate in describing the User Story or Acceptance Criteria;
• Each team member relies on the fact that other colleagues understood the requirement;
• Delays occur due to ambiguities in the User Story, which can lead to late delivery of functionality;
• We do not implement the requirement for lack of details, and we must resume things;

How can Scrum Masters help the team overcome these obstacles?

• As Scrum Masters, we have to reach a certain level of understanding the product and ask questions. This can open up some ideas among the team members;
• We encourage the team not to be afraid to ask questions as foolish as they may seem at first glance;
• The team can look before the refinement, 30 minutes over User Stories. And try to check the code base in that area to prepare questions;

2. Create a common understanding of how to estimate User Stories

In most cases, a newly formed team contains members who have been part of other teams. Teams that had their own working model. 

A working model based on the context of the respective product. Which also includes different ways of estimating User Stories.

Here are some challenges that might sound familiar to you

• What to consider when we estimate a User Story;
• How can a QA estimate what a Developer does, and vice versa;
• What is the maximum number of Story Points that a User Story can get;

What techniques can a Scrum Master apply in such situations?

1. When I start working with a new team, I start by holding a workshop on estimates. We work with the Affinity estimation technique and real User Stories.

The team tries to find the baseline that will guide them in estimating future User Stories.

Also, effort, uncertainty, and risk are the aspects we need to keep in mind when we estimate.

2. One question I often hear is how can a developer include the testing part in his estimate if he is not the one doing it. And vice versa. The reality is that there is no ground rule, it comes with the experience of working together.

The estimates are nothing more than an opportunity for conversation. Each of the parties tries to explain to the other what they will do, and how difficult it is. Thus, many things can be clarified on both sides. 

In this way, they all reach a common understanding to which they can attach a complexity as realistic as possible.

3. The complexity of a User Story is as much as it is. We cannot put a limit on how much we estimate a User Story. If it’s too large, we break it down, until the resulting pieces are small enough for a sprint.

All we have to do is look at the most complex User Story we’ve had so far. Then, by comparison, we think about whether it is more complex than the most difficult we have worked on. 

And from there we can say if it is twice or 3 times more difficult, and so we assign it an effort.

3. Break down large User Stories into pieces that still deliver value

Although it may seem like a simple activity, it is not enough to take a large User Story and start extracting various functionalities separately. We have to consider a number of aspects when trying to do this.

Why some teams are afraid to break down User Stories

• They don’t know how to break it down so that each User Story continues to deliver value;
• Testing is made on too small areas when it could cover a larger area;

Testing should not become difficult. If the changes made are in the same area, it makes little sense for the QA to check the same part countless times, with a slight change. 

Depending on how difficult it is to test on that functionality, you can agree with the QA to do the testing when all those little User Stroys are complete. Of course, we refer only to the User stories in that sprint.

Each User Story must be a deliverable that brings value and can be used by the end user.

Some User Stories can have an effort that is at the limit of the team’s speed and could be delivered in a sprint. But dividing it into smaller working items can bring a real advantage in the speed with which we will deliver it.

4. Build a structure for the User Stories that are refined

For any User Story, we can describe what it entails in terms of implementation. Such as database changes, API creation, and both backend and frontend. Knowing all these aspects, you can create subtasks for that working item.

What are the advantages when you structure your User Stories into Subtasks

• For a User Story that is very complex but we can’t break it down, we create some milestones. Thus, even if we pull the story through several sprints, we have some checkpoints to check at the end of the sprint;
• Simplify pair work. Often to complete a story faster, 2 developers can work on the same user story simultaneously. Having divided it into several subtasks, each can work on a subtask;
• It helps us with estimates. Decomposing the User Story technically, we better understand the complexity of this item;
• We can conclude that another User Story should emerge. This can affect estimations or priority;

5. Help the team collaborate and write acceptance criteria together

The responsibility of the development team is to identify, together with the Product Owner any information that is missing from the description of the User Story.

Of course, things are simpler when the team already knows the product. But what do we do when it’s something completely new to them?

• In each sprint, I invite my team, within a 2 hours timebox to look over the working items that we are going to refine. Thus, they will be better prepared for the discussion that follows;
• Another thing we do is to invite to the Refinement session, another developer who already knows the product. Even if he is not part of our team, due to his knowledge of the product, he brings very useful information;

6. Have and follow the Definition of Ready for the User Stories that are refined

Does your team have a DoR that they agreed on? If not, it’s time to create one. 

Here is why:

• If you take into the sprint a User Story that has no mockup attached;
• If you work on User Stories that have no Acceptance Criteria;
• If a User Story without description is accepted into the sprint;
• If the User Story needs confirmation from any of the stakeholders before you can start to work on it. And you still accept it into the sprint;

Then it means your DOR is incomplete or non-existent. Of course, there will be exceptions when the situations above will still appear, but it shouldn’t be the rule.
You have to ask yourself if the team has everything they need before they agree to deliver something at the end of the sprint. Because without enough information at this stage, many delays occur during the sprint. Which leads to not delivering the work in a timely manner. 

I’m very curious to hear about what other challenges you’ve encountered and how you overcame them. So if you want to share, please leave a comment below.