Five Tips to Overcoming Scrum Team Challenges So You Can Increase Your Velocity
In this blog, I’ll review five of the most common Scrum team challenges, whether you’re adopting Scrum for the first time or evolving your Scrum approach. Scrum, which can be difficult to master, requires teams to learn how to inspect and adapt. Teams must work together to understand and adopt the values and principles of the Scrum framework. Working with many Scrum teams over the years, I’ve developed strategies that might help you work through these common challenges. The effort is definitely worth it, and putting in the work can help you achieve the velocity your team needs.
Scrum works best when you use all the parts
Often, I see Scrum teams struggle because they don’t believe Scrum is successfully working for them. If this is the case for your team, I encourage you to evaluate how you’re using Scrum. Consider this: for a car to successfully operate, you need at a bare minimum a steering wheel, a motor, a transmission gear, and four wheels. Each part serves a purpose. Skipping one part means the car won’t operate correctly. The same is true for Scrum. Scrum prescribes three roles, five events, and three artifacts. Ask yourself if you can identify all these parts. Ideally, you should adopt the whole Scrum framework, focusing on the three pillars behind Scrum: transparency, inspection, and adaptation.
When teams are able to adapt their approach to reflect the whole of the Scrum framework, the hurdles become less challenging. Sometimes, teams discover that it’s only some part of what they’re doing that isn’t working; if that’s the case, you might find some of the other suggestions in this article helpful.
Schedule your Sprint Planning and Retrospectives
Teams that struggle to implement Retrospectives or Sprint Planning also struggle to start or evolve a healthy Scrum practice. Scrum works best if you do all the steps, so my advice is design a Sprint flow that includes all the four mandatory events and other key meetings. Each event holds its own purpose and benefit. Planning will help you ensure all the events are scheduled, take place at the same time, and ideally, in the same place (physically or virtually). Scheduled, consistent events help create a healthy and regular cadence.
Another key Scrum practice: timebox your meetings! As you can see from the example table below, if you included all Scrum events (and timeboxed them), your team would still have 85% of their time available to code.
| Events | Hours Committed |
| 2 Week Sprint | 80 |
| Daily | 2,5 |
| Planning | 4 |
| B. Refinement | 2 |
| Review | 2 |
| Retrospective | 2 |
| Meeting Time | 12.5 hours (15.63%) |
| Dev. Time | 67.5 hours( 84.38%) |
You might be tempted to skip an event like Retrospectives, but resist that temptation! Retrospectives provide a critical opportunity for teams to inspect and adapt, encouraging continuous improvement. For instance, if your team feels like Sprint Planning isn’t useful, they could discuss the issues and how to improve them during the Retrospective.
Define and agree on what “ready” means
When User Stories are frequently sent back due to missing details or Key Acceptance criteria, this can signal misalignment on the definition of ready. In fact, this is one of the most common issues Scrum teams face.
If this is your issue, make sure you implement a Definition of Ready (DOR). Having a DOR ensures that stories contain all the minimum necessary information before being pulled into the Sprint, without having to meet again. In my opinion, DOR serves as an unwritten contract between the Product Owner (PO) and the development team, establishing a common and agreed upon understanding of the minimum necessary information the PO needs to include in the card. DOR is different from the definition of DONE.
If the card meets the DOR prior to the Sprint start, the team can more accurately estimate what needs to be done and the amount of work required to complete the User Story.
What should be in your DOR? Here are some elements to consider including in a rock-solid DOR:
• A clear description of the issue
• Clear and precise Acceptance Criteria for each User Story
• A video or image highlighting the change
• The data set to be used or clear steps to replicate
• At least one discussion of the User Stories prior to its being included in the Sprint planning meeting
• Previously reviewed and agreed upon Acceptance Criteria
• A User Story and story points that have been estimated together with the team
Note that this list includes elements for the cards as well as requirements of the process.
When you create your own DOR, instruct your team to sit down with the PO and agree on the minimum information needed on the card. That will define your starting point. Your DOR might require several iterations with your team. That’s OK, and it’s part of the team process.
Once you’ve finalized your DOR, make sure your team validates that the user stories meet the DOR prior to the Sprint Planning, ideally during the Backlog Refinement meetings. The DOR acts as a quality gate and can significantly improve the Sprint execution.
Avoid arbitrarily assigning story points
Another very common issue, and one of my personal favorites to resolve, happens when teams aren’t sufficiently involved in estimating story points for User Stories or aren’t given the opportunity to revisit the story points. If this is your team’s situation, it’s a perfect time to review the basics of relative estimation.
You can avoid this Scrum team challenge by making sure to:
• Design a Sprint flow that guarantees regularly scheduled Backlog Refinement meetings
• Establish a DOR (see above) that is enforced before Sprint Planning
• Use the Retrospective to talk openly about how or why the team hasn’t been involved in estimating User Stories
Your team should be able to share feedback on the amount of effort required to complete the User Stories as a key input for the story point assignment. They should also have an opportunity to modify the story points before committing to complete the work before the Sprint begins.
These issues will typically resolve when teams begin to consistently hold Sprint Planning meetings, because it’s at that time the team must agree to the Sprint Backlog. I’ll say it again: every part of the Scrum process reinforces every other part.
Keep a focus on the present
Sometimes I see teams focused so intently on future tasks during their dailies that they lose sight of more immediate stories. They spend more time refining User Stories than they do on identifying and resolving current challenges or working on team alignment.
To make sure this Scrum challenge doesn’t happen for your team:
• Assign someone, ideally the Scrum Master, to facilitate your meetings. Be sure to timebox your meetings. Having someone keep track of time and remind the team of the meeting objectives keeps the meeting focused and on track.
• Prioritize the Product Backlog and keep the team informed on the Sprint goal. If the Backlog is prioritized, then the PO, the ScrumMaster, and the team will all know that they are working on the most important items. They can all pay more attention to what is going on with those items and how to remove any impediments they face.
Starting and growing a Scrum practice is hard, but worth the effort
You’re not alone if your Scrum team challenges seem overwhelming. Working through the challenges is part of the process, and will help you grow as a team. To ensure you succeed, start by defining a Sprint flow that accommodates the cadence of the Scrum events and the Backlog refinement meetings. When your team commits to “stick to it” for a few Sprints, including showing up for meetings and timeboxing events, it’s easier to stay focused on the event objectives. And then your team will also have the chance to discuss issues and estimation problems at the Retrospective. All of this will encourage the team to become more effective and improve their communications.
In the car example I shared at the beginning, you can easily see that when you skip key components or assemble the components incorrectly, you won’t be successful. You can’t steer a car, for example, without a steering wheel. All the parts of Scrum work together and reinforce each other. Making sure you’re using all the parts of Scrum will help lead your Scrum team to business success.
Adopting an Agile mindset is much more of a journey than a single event. Invest the time to understand the principles behind the Scrum practices. Make sure new teams and/or team members have plenty of time and support to learn and master Scrum skills. Allow them to inspect and adapt to the new ways of working. When you do, your team will begin achieving the business results the entire organization is longing for, starting with the fact that your team will increase its velocity!
