3 Reasons Why Scrum Teams Fail to Create Increment in Sprint
One of Scrum’s fundamental principles is delivering measurable value in every Sprint. However, many organizations and Scrum teams struggle with this. Based on my experiences as a Scrum Master and now consultant, the top three causes are non-cross-functional Scrum teams, the absence of a proper Sprint Goal, and misunderstanding the benefits of small increments.
1. Non Cross-Functional Scrum teams:
Scrum teams often struggle to make decisions on creating value for customers. Some don’t have the essential skills required. Others, despite having the skills, are not empowered to make decisions.
I regularly observe the following situations:
- Product Owner must seek consent from Stakeholders to order the Product Backlog.
- Developers must externally validate the database architecture.
- Developers must perform mandatory code reviews with seniors outside the team.
- Members of specific departments manage UI design and deployment.
The common thread in all four scenarios above is external dependencies that stop teams from making decisions. Consequently, people start blaming others, particularly those working outside the team, and this cycle never seems to end.
True cross-functional Scrum teams with dedicated members possessing all necessary skills and decision-making authority are rare. Ironically, only such a team can confidently commit to producing releasable Increment in a Sprint. Even if the team falls short, it becomes a learning foundation. It allows that team to identify gaps and gain insights, driving continuous improvement in each Sprint.
2. Not having a proper Sprint Goal:
I consistently observe that a Scrum team without a Sprint Goal lacks the focus, motivation, and collaboration needed to create something usable within a Sprint. Some teams, even with a Sprint Goal, struggle to create a proper one with the right quality and process.
Here’s how Sprint Goals go wrong:
- The Product Owner sets a non-negotiable goal at the start of Sprint Planning.
- Developers, Product Owner, and Scrum Master do not collaborate during goal crafting.
- The Scrum team needs to validate the Sprint Goal with Stakeholders before proceeding.
- They are not formed with equal ownership by all Scrum team members.
Garbage In Garbage Out, these bad processes create bad Sprint Goals like:
- Task-oriented goal (e.g., completing only the API for the dashboard).
- Multiple goals in different directions (e.g., finishing the landing page, integrating the new payment service, and completing research on video streaming optimization).
- Vague goal (e.g., making the search page reliable).
Designing a user interface or creating an API, individually, may not provide value to end users. These faulty sprint goals need to be more value-centric, negotiable, specific, and measurable.
3. Misunderstanding the benefits of small Increments:
Companies go for planning-heavy, release-heavy and stakeholder pleasing approach at the expense of customer value for many reasons:
Reason 1: The appeal of big release
There’s a prevailing desire to showcase something substantial and grand. We assume small values don’t entertain Stakeholders. We are inclined towards impressive releases, sending long emails with laundry lists of features to organizational leaders, seeking their appreciation in company meetings. Essentially, we prioritize pleasing our managers and executives over satisfying customers.
Reason 2: Love for planning
Organizations love planning. Let me share a story from a market-leading multinational company where I worked. I tried to coach them to shift away from big planning and instead focus on frequent assumption validation.
I failed miserably.
They design pixel-perfect, high-fidelity interfaces and hire a few beta testers to validate the prototype. The next step is all too familiar: asking the developers how much time it will take to build. The 2-week sprint primarily assesses how many story points developers have achieved against their velocity to measure predictability.
Reason 3: Obsession with predictability
Story points can be easily manipulated, and this initial success pleases managers in the initial sprints. However, as the project progresses, integrating the work from multiple sprints becomes time-consuming, and deadlines are frequently missed. Quality is also compromised due to last-minute stress and deadline pressures. Then, we punish the team for not being predictable with something where unknowns outdo knowns by a huge margin.
We are obsessed with talking about Velocity because it is easy to measure with readily available data from our task management tool. But, we don’t talk about the impact of the last feature we delivered, because it is far more difficult to measure.
Recommendations:
Many of us have faced these situations in our workplaces. This is how we end up exploiting Scrum. So, how can we address this?
Step 1: Understand the essence of the Sprint. The Sprint aims to create something usable, that we believe will add value to end users and can be validated promptly. Frequent validation of our assumptions is the best approach for minimizing risk while developing a complex product. Determine the sprint length thoughtfully, considering how regularly we need to validate our assumptions and how much time is required to create something measurable for that validation.
Step 2: Form a cross-functional team capable of creating a working, releasable increment in every Sprint. Creating such teams is not an easy feat, as it demands a radical change in the existing organizational process and team structure. It requires courage to shift the focus from departmental efficiency to value-driven effectiveness. The recommended strategy is: initiate this transformation within one team, assess the impact, and gradually extend it to other teams.
Tip to Scrum Masters: Non cross-functional teams often find excuses by blaming others. A Scrum Master’s dharma is to uncover everything that allows excuses and work towards building cross-functional characteristics in the team.
Step 3: Empower the cross-functional team to craft a proper Sprint goal. This means we are planning for a Sprint of one month or less, nothing bigger. Let the Scrum team self-manage to create something releasable towards the Sprint Goal in every Sprint.
Here is the actual Sprint Goal from one of the teams I am currently coaching: “Enhance user experience by improving system reliability, achieving X% uptime, and seamlessly supporting N concurrent users.”
Step 4: Measure the impact of each Increment and use the learning for future decision-making. All in all, utilize Sprints as a regular cadence for optimal learning, making adjustments to enhance product value, quality, and collaboration among team members.
Do you encounter other major challenges hindering incremental iterations? How are you addressing them? I would love to hear from you.
