We identify many challenges when implementing Scrum and these challenges will differ from team to team. I’m talking below about 4 of them and how to overcome these challenges.
1. First-time estimates with a team new to Scrum
In Scrum, we use relative estimates to assign sizes to work items. And it might seem difficult in the beginning because day by day, we are used to making estimates in absolute units, such as hours and days.
Why is it challenging to estimate relative sizes for the first time
- It’s easier for us as individuals to estimate using absolute values – estimating in relative sizes, such as story points or T-shirt sizes is an empiric evaluation of the complexity, risk, uncertainty, and effort combined. Whereas, an absolute evaluation of the work is based on known and repetitive information. And when we know how much it took us to do something in the past, it’s easier to estimate in hours or days.
- It’s difficult to make a mindset switch – I saw teams that are new to scrum that have a hard time thinking in a more abstract and flexible way. Instead, they need to know every detail of the problem, know the system, the code, the design. Others might even try to correlate the relative estimations with days. But this is only an absolute estimation marked with story points or T-shirt size for the sake of assigning a relative value.
- We don’t have a baseline to guide us – another thing teams why teams have a hard time assigning relative sizes is because there are no guidelines in the beginning. How do you know what working item is a 3 SP, 8 SP, or which one is an S or XS? This is something that scares teams because they think these estimations are a contract. But the beautiful thing about relative estimations is that they are more accurate and flexible and teams can get better at it in time. And over time, the team will know how many points they complete in a sprint.
How to help teams that are new to Scrum to estimate in relative sizes
There are multiple techniques you can apply with your team to help them start with relative estimations. The first step is to create your baseline. This is the first work item after which the team will guide.
This works with teams that are new to Scrum, but also with teams that are newly formed. Coming from other projects, people may have different perceptions about the effort of a 5 SP or M work item.
I like to start with affinity estimation which works easily with remote teams as well. It’s a simple technique that allows you to order fast and group items in chunks of similar work.
I randomly choose one work item and I place it on the board. Then we take the next work item. We compare it relative to the first one and place it above if it’s more difficult or below if easier. Then we do the same thing with the next items and compare them to the ones before.
Then, starting from the bottom, we assign story points to the items and use them as future references. You’ll find many variations for this technique, you can choose the one that suits you best. You can find the process nicely explained in this video.
Types of relative estimation techniques
- Affinity estimation – Works very well with teams that are new to Scrum or newly formed teams.
- Story points estimation – it’s more accurate. And it’s easier to track data such as velocity or making forecasts.
- T-shirt sizing – I find this technique useful when we need a change of mindset from hour estimations to relative estimations.
- Other techniques – Bucket estimation, TFB/NFC, Big/Uncertain/Small, Dot voting, Ordering protocol, Divide until Maximum Size or Less.
I encourage you to read about these techniques to see in what scenario they fit the best. And depending on the situation you are in, apply the one that suits your team best.
2. Refining the backlog for the next few sprints
Challenges many teams encounter
- Running out of time and not talking about everything you set out to – might be an indicator that you don’t focus on the right things in these sessions. During refinements, the team should talk about what is the problem to be solved, and identify possible approaches that will solve the problem. This is the primary purpose of these sessions.
However, I’ve seen many times teams falling into endless technical discussions. And while it’s very difficult to avoid them, we should be just careful not to go too deep into details.
- There’s no definition of ready – the definition of ready should be something the entire team agrees about. It’s important to know how much information is enough for the developers to understand what they have to do. This helps the Product Owner prepare in advance for the refinement, with just enough details that can lead to a productive conversation.
- The Product Owner doesn’t explain the What and the Why behind the work item – which leads to having teams that are not engaged enough in the discussion. The Product Owner should set the context for these conversations. This means they should present what are the obstacles and the needs of the end-user. And why should we solve their problem.
When the Product Owner presents the solution instead, some teams simply accept what they are told to do. The Product Owner should challenge them into finding the solutions. I was this type of Product Owner too, without even realizing it.
In one retrospective I was complaining about them not taking part in adding acceptance criteria during refinement. I did that because it happened several times for me to expect something to be done, and it wasn’t. And their response was always that they did what was in the description. And if I wanted something more, it should have been in the AC.
So one developer told me they feel they have no say in what’s described in the work item. And I always come and tell them what to do. It hit me for a moment, but I realized he is right. As I let them take part more in finding the solution, they felt they have more responsibility. So they were more careful with what the outcome of their work is.
How we run effective refinement sessions
The Product Owner prepares the work items prior to the refinement session, considering the definition of readiness that was agreed in advance. As a Scrum Master of the team, I make sure I ask him before the session to make sure the items are ready to be presented.
The Product Owner makes sure he has shared the entire context of the problem to be solved with the team.
When I see the team spending too much time on a work item, I simply ask them if we need all that information at that moment. Or if it’s something that they can discuss once they’ll work on that item. They often say it’s important to have that conversation so they can estimate the item. And what I do in these cases, I ask them to wrap it up in 2 minutes, and then will estimate the PBI in the planning session, after they had the chance to discuss it a bit more.
3. Having constructive discussions in the Sprint Retrospective
We have sprint retrospectives because we want to look at how we did things, what was the outcome, and how can we improve ourselves to become more effective. There are problems in every team. If everyone says that everything is great, that’s my cue that something is going wrong.
Why Sprint Retrospectives are difficult
- As Scrum Masters, we might not go prepared with the right topics to discuss – sprint Retrospectives are not a useful tool if we don’t do it right. We are all familiar with practices such as “Start/Stop/Continue”, or “What went wrong/ Improvements”. But they have no meaning if we don’t back them up with real data of what happened during the sprint.
- The team is pointing fingers at people outside the team instead of looking at ways they can improve – this comes from the way we, as Scrum Masters, present the goal of that retrospective to the team. Everyone has to know that we identify problems and we try to find a solution by the end of the meeting.
Some other times, there is frustration among team members. This can make them not want to find solutions anymore, just wait for others to do it. These cases are the most difficult, but here’s one thing that I do when I see this happens in these sessions. I choose a topic, only one, and we discuss it until they find some action points for them. This can distract their attention from the other many frustrations they have.
What to do to improve the retrospective activity
I try to do different activities in refinements to avoid getting bored by having the same discussions repeatedly. As Scrum Masters, we have to prepare at least one hour before refinement. Or sometimes depending on the activity. For example, you could put together some working agreements for everyone to follow.
These can be things like:
- running unit tests
- letting other team members know when a task is ready for a code review
- peer programming on at least one work item per sprint
I also organize workshops on different topics, depending on the stage the team is on. When a new team is put together, the first workshop I hold with them is around estimation techniques. People coming from different projects have different habits.
I got a lot of useful information from Agile retrospectives: Making good teams great. It contains a lot of step-by-step activities that you can use with your team. Or you can check out this website.
The most important aspect is the data backing up the conversations in your retrospective. Burn-down charts are a great tool for starting the conversation. You can identify patterns, such as work items that spend too much time in a specific area. But whatever metrics you bring, make sure the team is not feeling blamed for something they didn’t do right. It should be an opportunity for identifying future actions that will make the team be more effective.
4. One on one sessions – Scrum Masters & Developers
The purpose of one on ones
I consider one on ones to be a great opportunity to get to know each other. Knowing each other is important for building trust and a good working relationship. As Scrum Masters, we should be careful not to sound like a manager. Delegation and technical feedback should come from their direct managers.
Challenges you may face in one on ones as a Scrum Master
Having no technical background, to me it happened many times that I am not accepted various suggestions about how to organize, estimate, split work items, and so on. Having experience with many teams, I see what is not going well and identify various improvements. And what I do in these cases is simply ask the team to try it out for a short period, to see how it goes.
If you have a technical lead in the team, things might get easier. I’m working closely with my team’s lead and when I have a suggestion about making a change, or if I see something not going well, I talk with him first. And then decide together what we can do next.
What do I do in my one on ones with the team
I ask them open questions, such as
- How they feel about their work?
- How they feel about the team, and how do they work together?
- What changes can make them be more efficient?
- What are their day by day challenges?
- What are their goals?
- How can I support them?
I look forward to hearing about your challenges. You can leave a comment below and let me know how you overcome them.
