Six Dangerous Pitfalls Scrum Teams Often Face

There’s no such thing as one size fits all. My whole life, I heard that sentence in different contexts, but I wonder if Scrum or any other Agile frameworks strive for this approach of one size fits all. I’ve worked for several companies, from startups to massive corporations, from South America to Europe. I’ve been in many different segments, the public sector, automobile, online shopping, and the list goes on.

What astounds me is not the flexibility of the Scrum framework, but the common pitfalls I faced anywhere I’ve been

When I look back, there are some things I wish I knew, yet nobody told me. I had to figure out my mistakes on my own. Allow me to share the six common pitfalls I recognized with most Scrum teams. Hopefully, you can avoid them and create value faster with your teams.

The following traps come mainly from a Product Owner’s perspective, but may be beneficial for any team member to help the team escape from such traps.

#1 Bullshit Management

A massive trap is starting a Scrum without having anyone with relevant product management experience on board. The result is frequently terrible. Instead of focusing on what generates value, the team ends up dealing with a lot of bullshit. I call that bullshit management.

Being a steady team goes beyond any Agile framework. Agile teams cannot succeed without solid product management skills. For example, the Scrum Guide tells us what our responsibilities are, but not how to live up to them. Here are some traps you will eventually face:

• Please stakeholders: Prioritization is key to success. Yet, it’s the reason for many sleepless nights. Product Owners face pressure from all layers of the organization, which is why it’s easy to bow down and lead teams in pointless directions. Great Product Owners strive for commitment instead of consensus. They agree to disagree and prioritize delivering value instead of pleasing stakeholders.
• Ignore end-users: No matter which product or service you offer, it exists because somebody gains something from it. It’s impossible to build valuable products without profoundly understanding real end-users, yet it’s very common to fall in love with solutions, ignore the end-users, and inevitably create something stakeholders love—but users couldn’t care less about.
• Overlook the outcome: Creating features is one thing; delivering value is entirely different. All features are irrelevant until end-users can benefit from them. Measuring impact is a complex task, yet it’s core to success.

No Scrum team can create enduring value without sound product management.

#2 Wishlog Management

A dangerous pitfall is descending your Product Backlog into a wishlog. Everything anyone asks of you becomes an item inside your backlog. This is one of the reasons Scrum teams often become feature factory teams.

An excellent Product Backlog contains problems to solve instead of requirements to implement. Here are some traps you need to be aware of:

• Dinosaurs: Backlog items should have a short lifespan. If they don’t make it to a Sprint in a couple of months, you should remove them from the backlog. Backlog items are like milk, not wine; they spoil fast. Old items become obstructions to new ones.
• Too much details upfront: The level of detail you put into the items will define how the team will tackle them. If everything is defined upfront, the team focuses on execution. However, if you bring up a problem and clarify why solving it is essential, you open the door to creativity. By bringing up open questions, you encourage people to search for answers.
• Protect the backlog: The Product Owner owns the Product Backlog, but that doesn’t mean you should be the only one to put items there. Let stakeholders and team members contribute to the backlog, and then you can decide what will end up in the Sprint and what will go out the window.
• Everything goes to the backlog: Without clarity on what to achieve, the backlog becomes an extensive wish list. It’s vital to have clarity on the goal, guaranteeing that only items that would contribute to it go in.

One of my key learnings is to never start managing your product backlog until you agree on which goal you should pursue. I like saying:

No Goal is a no-go!

#3 Pointless Refinement Sessions

I had horrendous and incredible experiences with refinements. I have yet to find a perfect recipe for success, but I have identified what leads to disappointing results:

• Focus on the solution: The session should be about building a shared understanding of the problem that needs solving instead of focusing on the boundaries and details of solutions. First, the team should clarify the problem and only then can they talk about solutions. If you invert that, you get a team of executors instead of problem-solvers.
• Refine pointless items: Deciding what to refine is critical. The team should refine things they can work on soon. For example, they waste their energy when the team refines something that won’t be included in the upcoming Sprints. If you have nothing new for the upcoming Sprints, it’s better to skip a session than focus on something irrelevant.
• Endless tech discussions: During the sessions, it’s easy to fall into deep tech discussions, though that’s not the goal of refinements. Developers often rush to clarify tech aspects because they are pressured to give precise estimates and match arbitrary deadlines.
• Focus on estimates: Providing an estimate doesn’t represent a commitment to an implementation date. The process of estimating is more critical than the estimate itself. For me, estimates show whether the team members share the same view on the complexity of the items.

#4 Fuzzy Sprint Planning

When a group of people shares the same goal, they collaborate intensively to reach it. That’s why planning the Sprint is critical to fostering collaboration. Nevertheless, it’s easy to stumble into some pitfalls and transform Scrum into a waterfall approach. Here is what I suggest to avoid at all costs:

• Lack of Sprint Goal: The first and most crucial part of any Sprint is its goal. Without that, the team has little to no reason to collaborate. When the Sprint Goal is blurry or inexistent, teams find themselves under pressure to deliver more output, leading to compressed Sprints focused on delivering tasks instead of reaching a goal.
• Chinese soup: A Sprint is not supposed to be like Chinese soup; you need to pick carefully what goes in and what doesn’t. It’s not about choosing what fits the team’s capacity (also known as WIP limits); it’s about deciding which problem is worth solving. A diverse Sprint will lead to constant context switching, low performance, and ultimately a watered-down result.
• Divide and conquer: I’ve used fragment Sprints, comprised of 50% new features, 20% bug fixes, 20% tech debt, and 10% slack time, for example. Well, on the surface it makes sense, but when I understood the impacts, I stopped doing so. Allocating specific time for bug fixes or tech debt is impossible. Solid Product Owners focus on crafting a relevant Sprint Goal and then let the team decide what they will do.
• Squeeze the lemon: A little bit more, please! Squeezing the team is a recipe for disaster. Hacking ideas into planning causes distraction and confusion. For example, before the planning you have an idea, and instead of reflecting on it and conveying it to a refinement session, you decide to include it in the next Sprint, meaning that the team will have to inject refinement into the planning. Of course, you could treat that as an exception, but it should not become the rule.

#5 Meaningless Daily Stand-up

How energetic are your Daily Stand-ups? Do people want to be there or would they rather be anywhere else? Depending on your answer, you will understand your problem.

Although Product Owners can attend the Daily Stand-up, this event is not for them. The Daily Stand-up goal is to ensure developers get a step closer to the Sprint Goal. I’ve come across several anti-patterns with Product Owners:

• Status report: The Product Owner uses the daily as a status report; they name speakers and monitor their progress. Well, that’s a massive anti-pattern. Product Owners should never run a Daily Stand-up, and if they do participate, they should be there to listen and help instead of being a traditional Project Manager.
• Be the boss: The Daily doesn’t start without the Product Owner. Once the Daily starts, the Product Owner listens carefully to each team member and then defines who does what and when. Developers become passive, and they wait for the Product Owner’s instruction.
• Distractions: The Product Owner comes to the Daily and hijacks the session for special requests. Instead of helping the team progress towards the Sprint Goal, the Product Owner ends up adding more to their plate. Sometimes an “urgent” situation appears, and a developer needs to support the Product Owner for a day or two. Quick fine-tuning is required to get more support from stakeholders.

#6 Tedious Sprint Review

Are your stakeholders eager to attend Sprint Reviews, or do they constantly find excuses to not be there? Think about it for a minute.

Every Sprint ends with a review in which the team presents what they achieved and gets feedback from the stakeholders. Until now, I’ve experienced a wide variety of Sprint Reviews, from energy-draining sessions to powerful and inspiring ones. Generally, Product Owners have a strong influence on the results. Here is what they shouldn’t do during such sessions:

• Take the stage: Product Owners become showmen and keep developers behind the curtains. Proudly, they present all the features that the team achieved during the Sprint and ensure that developers remain silent once a stakeholder provides feedback, because the Product Owner owns the show. I had several sessions like that, and developers inevitably disengaged and eventually lost interest in the product.
• Make promises on output: Stakeholders tend to ask for new features during the Sprint Review; that’s normal. However, how Product Owners address such requests is critical to the team’s success. Bad Product Owners will make promises and create new backlog items, whereas good Product Owners will strive to understand the need behind the wishes.
• Focus on Sprint increments: Only showing the result of the Sprint is often not enough. To engage with the stakeholders, it’s vital to connect the dots by showing how the increments change their lives in their context. Ignoring the big picture will result in low engagement.
• Ignore the impact: Focusing solely on the output of each Sprint will not help stakeholders understand the real value that the team created. As the Scrum Team gains clarity on the outcome generated by previous Sprints, they must showcase that during the Sprint Reviews.

Without clarity on the outcome, Product Owners will face a hard time gaining support from stakeholders.

Final Thoughts

As embarrassing as it can be, I stumbled into all of the pitfalls I described. Sometimes, I still do. I learned that being a great Product Owner is not about being perfect; it’s about being humble and owning up to our mistakes.

Once we can see our flaws, we can progress and become a better version of ourselves.