The Scrum Master's "Four Sprinkles" Habit: Why Your Team is Just a Group of Freelancers
Is your team a unit or just a group of freelancers sharing a Jira board? Learn why "Four Sprinkles" (individual goals) destroy flow and how to fix it with slack.
I was reviewing a transcript from a coaching session last year when I spotted a bizarre typo.
The software claimed the team was struggling because they had "four sprinkles."
I laughed. It was clearly a weird glitch in the transcription: it meant "Sprint Goals." The team had four developers, and during planning, they had committed to four entirely separate objectives for the two-week iteration.
But the longer I stared at the word "sprinkles," the more I realized the computer was dead right.
They didn't have goals. They had decorative toppings. They were sprinkling unrelated tasks across the Jira board just to make sure everyone stayed busy. Every developer had their own isolated objective. Every developer was 100% utilized.
And absolutely nothing was getting finished.
The story of this team, a group of highly capable engineers drowning in unfinished work, is one where a false sense of efficiency masked a total breakdown in collaboration. We think giving everyone a discrete goal makes them an efficient team. The outcome? They were wrong anyway. They were just a group of freelancers sharing a Jira board.
The Illusion of Team Identity
I used to let this happen. Early in my career as a Scrum Master, I thought my job was to make sure the board was full and no one was blocked. I viewed an empty queue as a failure of planning.
I remember working with a team that operated exactly like this. We set our Sprint Goals every two weeks, but the confidence behind them was non-existent. They weren't a rallying call to get the team to focus. Every sprint, we completed some work, but I never heard any real energy in their voices about achieving a collective objective.
Fast forward to the last day of the sprint. Half the work was incomplete. We asked the team if they completed their Sprint Goal.
Silence.
Finally, one person looked down at their desk and said, "...yes, I think so."
That is a problem.
That was the moment it hit me. With Sprint Goals, it is either F*ck Yes or Hell No. Both of those answers are completely acceptable. Both give the team direction to learn and improve. Sitting in the middle, telling ourselves that the team has completed the work without actually finishing the job, is a massive disservice.
When you have four sprinkles instead of one goal, you guarantee that middle ground. You guarantee the "...yes, I think so." You create a culture where developers treat their teammates like NPCs in a video game, people who happen to exist in the same environment but are entirely focused on their own individual fetch quests.
The Science of the Traffic Jam
Why do we do this? We do it because organizations are terrified of idle hands.
We fall into what Henrik Kniberg calls the Resource Utilization Trap. Management looks at a team of four and assumes that if even one person doesn't have a dedicated task, the company is burning money. We focus on individual busyness. We treat developers like machines on a factory floor.
This isn't just a vibe check. There’s cold, hard math behind why this fails.
Don Reinertsen's queueing theory proves this in The Principles of Product Development Flow. Pushing capacity utilization past 80% causes exponential queue growth in product development.
Think of a highway. At 50% capacity, cars move at the speed limit. At 80% capacity, one driver taps their brakes and you get a three-mile traffic jam. Jira works exactly the same way. When you keep every developer 100% busy with their own goal, you create gridlock.
Think about the reality of software delivery. Developer A eventually needs a code review, a database change, or just a second pair of eyes from Developer B. But Developer B is fully utilized working on their own "sprinkle."
Developer A is now blocked. They pick up another ticket to stay busy.
Now we're context switching. In their study of heavyweight project managers, Clark and Wheelwright showed that time spent on value-adding tasks drops 20% for every concurrent task added. That tax eats the team alive. You end up with a feast or famine cycle where nothing moves for eight days, and then twelve poorly-tested tickets get shoved into the "Done" column at 4:00 PM on the last day of the sprint.
An Integratz case study of a Fortune 500 insurance IT team looked at an enterprise group that finally stopped doing this. They shifted their focus from individual utilization to flow efficiency, minimizing wait times. They cut lead times by 48%. They doubled throughput. They didn't add a single person to the payroll.
They just stopped sprinkling tasks and started acting like a team.
The Fix: Singular and Collaborative
Looking back, I do not believe that I could have fixed my team by asking them to plan harder. I wrote about this trap in The Predictability Paradox: Why I Felt Like an Agile Fraud. We had to change the structural constraint.
I brought in Maarten Dalmijn's FOCUS framework. Dalmijn wrote the book on driving value with Sprint Goals, and his framework breaks down into five pillars: Fun, Outcome-oriented, Collaborative, Ultimate, and Singular. We used the FOCUS framework as a filter. If a proposed goal wasn't Singular and Collaborative, it went back in the oven.
I told the team we were dropping the four sprinkles. We were going to commit to one Singular goal. One objective that would require at least three of them to work together to achieve.
I know what y'all are thinking: "My team does support and features; we can't have one goal." I’ve been there. But even then, if you don't have a singular focus for the sprint, you aren't a team, you’re just a help desk with a Jira board. Pick the most critical outcome and make everything else "secondary flow."
The pushback was immediate and predictably frustrating.
"If we only have one Sprint Goal, I won't have anything to do by Wednesday," one developer argued. "I'll just be sitting idle."
My response? Good.
I want you idle. Because in software engineering, idle time is not waste. Idle time is slack. Slack is the mana you need to cast bigger spells. That’s the capacity you need to pair program when a teammate hits a wall. It is the breathing room to swarm on a bottleneck, pay down technical debt, or fix a flaky test that has been annoying everyone for six months.
As Kniberg noted, 100% utilization destroys flow. Focus on flow first, then utilization.
The Strategy Session Shift
We took a utilitarian approach in our task. We forced the issue. One goal.
The immediate wins were startling.
First, developers started pairing on tasks instead of working in silos. Because the goal was singular, they couldn't retreat to their individual corners. They had to talk. They had to share context and own the outcome together.
Second, the Daily Scrum completely transformed.
Under the "four sprinkles" model, the Daily Scrum was a boring, useless status update. It was four people standing in a circle reporting on their individual islands. "Yesterday I worked on my ticket. Today I will work on my ticket. No blockers." It was an exercise in compliance.
With a singular goal, the Daily Scrum shifted from a status update to a vital strategy session. The conversation changed from "What did I do?" to "How do we achieve the goal today?" They were looking at the board as a collective unit. They were identifying risks probabilistically rather than just stating deterministic facts about their own Jira tickets.
It is for this reason that I treat individual Sprint Goals as a red alert, more urgent than almost any other agile anti-pattern. If y'all don't share a goal, you don't share a team.
Reclaiming the F*ck Yes
We have to stop treating developers like isolated pools of capacity. We have to stop measuring success by how many story points are in progress at any given moment.
When you allow a team to commit to a wishlist of unrelated tasks, you are actively preventing them from doing their best work. You are robbing them of the opportunity to collaborate, to swarm, and to actually finish something meaningful. You are setting them up for the disappointing "...yes, I think so" at the end of the sprint.
Stop measuring busyness. Start measuring flow.
Try this Monday: Open your active sprint board. Look at the work in progress. Look at the stated Sprint Goal.
Count the actual objectives. Are you rallying around a singular, outcome-oriented target? Or are you looking at a wishlist of four different features assigned to four different people?
If it's a wishlist, you don't have a team. You have a group of freelancers.
Take your longest list of tasks. Find the one that actually matters to the customer. Make that the only goal. Let the rest of the work be secondary. Watch what happens when your developers actually have the slack to help each other cross the finish line.
Your move.
Continue Your Journey
Free Resources Hub: Access tools, templates, and frameworks to help your team stop acting like freelancers and start delivering real value.
Monte Carlo Forecasting Calculator: Stop guessing and start thinking probabilistically about when your team's singular goal will actually be done.