Why Do Many Scrum Teams Put Energy Into Pointless Conversations?
Bookkeeping inside the team won’t yield more value
Bookkeeping inside the team won’t yield more value
What kind of conversations do you have with your team members?
Over the years, some discussions disturbed me a lot because they are unproductive and create no value. Many times I felt like we were doing accounting instead of product management. It seemed more important to agree on how we deal with “tickets” instead of figuring out how to deliver value faster.
Here is one situation you may have also experienced. A developer says, “Hmm. The ticket is done. You need to report a bug, and then I can fix what you mentioned.” Honestly, this kind of attitude frustrates me. I challenge the benefit of having bookkeeping with “Jira Tickets.” I don’t see a connection between delivering value and creating bug tickets for the work inside a Sprint.
Allow me to elaborate on what kind of conversations you should avoid with your teams and why. I’ve stumbled upon many situations where we wasted our time with pointless debates. I believe our energy can be better invested in meaningful steps to get us closer to delivering value.
The Ticket Obsession
I am surprised by how obsessed with tickets developers can be. If I’d get a dollar for each ticket request I received, I’d be a billionaire now. Some of the most common situations are:
Tech boundaries: during a refinement session, front-end or back-end developers urge to have a ticket for each of their tasks.
Don’t reopen a ticket; create a new one: reopening a ticket is unwelcome. It’s always better to create a new issue.
Not part of the acceptance criteria: it needs a new ticket if it’s not part of the acceptance criteria.
I wonder if our time is well invested in discussing whether something requires a new ticket or not. Instead of talking about what matters, following a process becomes more important than solving the problem itself.
From my experience, this ticket obsession is unsustainable and pointless, yet developers are not the ones to blame. At the root of this behavior is the absence of trust.
I perceive tickets as an insurance policy for developers. But why would developers need that? Reasons can widely vary. Let me share some common ones with you:
No Sprint Goal: the lack of a Sprint Goal forces the team to commit to a series of features to deliver instead of a goal to pursue.
Show progress: the Scrum Team wants to show they are making progress. Therefore, the more tickets they close, the better.
Process over individuals and interactions: the organization values more crafting a solid process instead of fostering collaboration.
Without a Sprint Goal, Scrum has no heart and it becomes a kind of WaterScrumFall.
It’s Not a Bug!
Is it a bug or a change request? Honestly, who cares? If it delivers value, why don’t we focus on doing that instead of defining whether it’s a bug or a task? Well, I wish it could always be that simple. Let me share a little story with you.
David: “Yesterday after the release, I talked to a seller. He told me that after he updates his orders, the portal still shows the old information. He noticed that after a couple of minutes, the portal presents the updated new data. I think that’s a bug.”
Björn: “That’s not a bug for sure. It’s how we designed. Due to our solution structure, it takes some time until the data is replicated, and therefore he needs to wait. If you want to change this behavior, please create a task, but not a bug.”
David: “Do you think this behavior is clear to our sellers?”
Björn: “Well. It might confuse them, but we can change that. But as I mentioned, it’s not a bug as the seller only has to wait a couple of minutes. The current behavior is the expected one.”
David: “Let me ask you a question. Why are you resistant to calling it a bug? Even though you recognize it’s confusing for the sellers.”
Björn: “Because my tech lead measures how many bugs are created per month. And we have a goal of reducing 50% of that compared to the previous quarter.”
When we define our focus based on fear, we reduce our chances of success.
Stupid metrics lead to pointless conversations. A better way is to focus on what leads to success instead of what avoids failures. For example, if we focus on increasing client satisfaction, the conversations will yield better results.
All We Want Is More Story Points!
Imagine the following situation, it’s the last day of the Sprint, and you still have many open items. A developer comes to you and says, “Let’s close some of our tickets and open new ones with what’s missing. Then we can burn some story points.” What would your reaction be?
I’ve faced a situation like that several times. Unfortunately, many times I was the cause of it. Sprint after Sprint, I used to report the number of story points we delivered. Proudly, I advertised how we constantly increased our throughput. I didn’t realize the pressure I put on the team. They felt they had to keep up to the expectations, and delivering less would be embarrassing.
My story points focused didn’t help us create value faster, but it made us have pointless conversations. What’s the sense of closing something half done and creating a “follow-up” for that? As Clayton Christensen said:
“It makes little sense to do things that make no sense.”
Delivering more story points has no relation with generating value. Scrum teams shouldn’t focus on arbitrary numbers. When we put our energy into pointless things, we cannot expect meaningful results. Like the example I gave, despite knowing the work was unfinished, we wanted to show more output while ignoring the outcome.
It’s Time to Focus on What Matters
We struggle to delight our end-users with outstanding products when our focus is on the process instead of the ultimate goal.
It doesn’t matter whether every person in the team has a ticket assigned. What matters is following a meaningful Sprint Goal and work every single day of the Sprint towards it.
It’s pointless to argue whether something is a bug or a change request. It’s more important to solve what impedes our end-users from progressing.
It doesn’t matter how many story points you deliver per Sprint. The only thing that matters is the value for the end-users and business with the Sprint Increment.
At the end of the day, all we want is to deliver value. That’s why we should focus our energy on actions that lead to value.
“Whenever there is fear, you will get wrong figures.” — W. Edwards Deming
