Most writing about backlog refinement assumes you already have a backlog to refine. But a lot of the engagements I walk into don't start that way.
They start with a blank board.
No user stories. No epics. Maybe a slide deck somewhere with some goals on it, or a long email thread where stakeholders have been talking past each other for a few weeks. The team is ready to build something. They just aren't sure what yet.
Growing Into the Solution Together
Before you can refine a backlog, you have to build one. And building one is not just a documentation exercise. It is a process of growing shared understanding across the team and the stakeholders about what the real problem is and what a good solution actually looks like.
They called it Sprint 0 at one shop. The goal is to get aligned before the team starts sprinting toward something.
Here is why that matters, and it comes down to something worth being honest about: documented knowledge is not the same thing as transferable skill. There is a common misconception that if a process is written down, anyone can execute it. A well-documented process can be replicated under controlled, well-defined circumstances. But real-world application introduces variables that require adjustment and learning every time a new effort starts. That is exactly why experience is so valuable in a developer, a consultant, or a Scrum Master. And it is why you cannot just hand a team a spec and expect them to run.
The knowledge about what to build, and how to build it well in this particular context for these particular users, cannot live in just one person's head. If the product owner holds all the context and the development team is just receiving tickets, you get a lot of building and not a lot of understanding. And when things change, and they always do, a team that understands the why behind the work is much better equipped to adapt than one that is just executing a list.
So the early conversations are as much about building that shared knowledge as they are about writing user stories. We are trying to understand the customer's real pain point. We are asking what problem we are actually trying to solve, who has it, and how we will know when we have solved it. Those questions take time, and the answers tend to evolve as the team learns more. That is expected. That is the point.
This is also why building a learning loop into the project from the beginning matters so much. Teams that pay attention to what they are learning sprint over sprint, and build that learning back into their process, get better. Teams that treat each sprint as an isolated execution exercise do not. The retrospective is part of this. So is refinement. So is taking time at the start to ask the right questions before anyone writes a line of code.
The Hidden Backlog Problem
Even when a team has a real backlog and a clear enough sense of what they are building, I often run into a different challenge: team members who cannot actually focus on the work.
Matrixed teams. Shared resources. People who are technically on the Scrum team but who also have operational responsibilities, a support queue, or two other projects competing for their attention. In Scrum we talk about sprint commitment, but if a developer can only realistically give the team 30 percent of their week, and does not know which 30 percent until it happens, commitment starts to feel like guesswork.
I have started thinking of those competing demands as hidden backlogs. The work is real. The team members know it is there. But it is not visible on the board, so it does not show up in planning conversations. Then it shows up mid-sprint instead, and suddenly the forecast is off and nobody is quite sure why.
What Helps
Getting the hidden backlog visible is the first step. That might mean adding a lane on the board for operational and support work, or building realistic buffer into sprint capacity estimates, or having an honest conversation with leadership about what dedicated actually needs to mean for the team to be able to commit to anything.
None of this is a perfect fix. Matrixed teams are genuinely hard to run Scrum with. Sometimes the right answer is to adjust the framework to fit the reality rather than keep fighting reality. Kanban, for instance, tends to handle variable capacity and interrupt-driven work better than fixed sprints do. It is worth having that conversation early rather than three sprints in when the team is frustrated and the forecast is consistently wrong.
But whatever framework you use, the worst option is pretending the hidden backlog does not exist. Commitment without visibility is just guessing with extra steps.
Do you have a team right now that is dealing with a hidden backlog? What happens when you try to have that honest conversation with leadership about what dedicated actually needs to mean?