How Requirements Flow from Product Owner to Developers
Scrum has no Business Analyst accountability. Here is how the work still gets done, using one team and one feature.
If you’re a Business Analyst moving into an agile team, one of the first things you’ll notice is that the Scrum Guide doesn’t mention you. No Business Analyst accountability, no requirements document, no sign-off stage. It can feel like your job has been quietly deleted.
It hasn’t. Understanding stakeholders, shaping requirements, and checking that a solution solves the right problem still has to happen. Scrum just spreads that work across the team and moves it closer to the product. When it goes well, it’s because everyone is clear on who decides what. When it goes badly, it’s usually because nobody is.
To show how, I’ll follow one team and one feature through a Sprint, and point out where the requirements work happens at each step. Terminology follows the Scrum Guide throughout.
Where teams go wrong first
Before any ceremony or template, there’s a more basic problem: nobody is clear who decides what.
Who says this feature matters more than that one? Who decides whether something is actually finished? Who looks after how the team works together? When those questions have no clear owner, work gets stuck in conversations, priorities shift weekly, and people quietly stop trusting each other.
Scrum answers these questions with three accountabilities. The Guide uses the word accountabilities, not roles, and the difference matters. It describes what someone answers for, not a job title or a seniority level.
The three accountabilities
The Product Owner
Is accountable for maximizing the value of the product. In practice, that means deciding what the team works on, and in what order. They manage the Product Backlog and make sure everyone understands the Product Goal. One person, not a committee, and the organization has to respect their decisions.
The Scrum Master
Is accountable for the Scrum Team’s effectiveness. They coach the team in Scrum, help remove obstacles, and make sure events happen and stay useful. They’re not the team’s manager and not a project manager. If the team can’t work out how to talk to a stakeholder who keeps interrupting, that’s a Scrum Master problem to help solve. Assigning the work isn’t.
The Developers
Are accountable for building a usable Increment every Sprint. “Developers” doesn’t mean only programmers. It means everyone doing the work of creating the product: engineers, testers, designers, analysts, whoever the product needs. They plan the Sprint, hold themselves to the Definition of Done, and adapt daily. Together, these make one Scrum Team. No sub-teams, no hierarchy inside it.
Where the Business Analyst role fits in Scrum
Scrum has no Business Analyst accountability, and that’s deliberate. The Guide describes what the team answers for, not who holds which job title. The analysis work still has to happen, so in practice BAs tend to land in one of two places.
Some sit with the Developers. Anyone doing the work of creating the product is a Developer in Scrum’s terms, and that includes analysis, discovery, and testing. Others work alongside the Product Owner, helping shape and refine the Product Backlog.
Either way, the skills are the same: understanding stakeholders, asking the awkward question early, and turning a vague need into something testable. What changes is the rhythm. Instead of finishing a specification and handing it over, you keep the conversation going while the product is being built.
Scrum in practice: one team, one feature
Let’s make this concrete. Imagine a team building a grocery delivery app. Priya is the Product Owner. Marcus is the Scrum Master. Four Developers, Ana, Dev, Lena, and Tom, cover mobile, backend, business analysis and testing, and UX.
Their Product Goal for this quarter: help customers complete a weekly shop in under five minutes.
Customer research shows that most people buy nearly the same things each week. So the team’s next big idea is a “Repeat last order” feature.
The Product Backlog
The Product Backlog is the ordered list of everything the product might need. It’s the single source of work for the team, and Priya owns it.
On Monday, “Repeat last order” sits fairly high. But it’s still a one-line idea. What happens if an item is out of stock? What if prices changed? What if the customer wants to remove two things before checkout?
This is where refinement happens, and where Lena’s analysis skills earn their keep. She talks to two customers and pulls the order data, then works through the idea with Priya. Which questions need real customer answers before building? Which can wait? It isn’t a separate phase. It’s ongoing, informal, and often the difference between a good Sprint and a chaotic one.
Sprint Planning
A Sprint is a fixed period of one month or less, during which the team creates something usable. This team runs two-week Sprints.
In Sprint Planning, the whole Scrum Team answers three questions: Why is this Sprint valuable? What can be done? How will the work get done?
Priya proposes a Sprint Goal: a returning customer can reorder their last basket in three taps. The Developers look at the work and discuss what’s realistic. Dev raises a concern that the stock-checking service is slow and could make the whole feature feel broken. They agree to include the work to fix it, and to leave out the “edit before checkout” option for now.
The result is the Sprint Backlog: the Sprint Goal, the Product Backlog items selected, and the Developers’ plan for delivering them. Notice who decided what. Priya set the goal and the order. The Developers decided how much they could take on. Marcus made sure the conversation actually happened and nobody was pressured into overcommitting.
The Daily Scrum
Every morning, for fifteen minutes, the Developers meet to inspect progress toward the Sprint Goal and adapt their plan.
On day three, Dev mentions the order history API returns inconsistent data for older accounts. That changes things. Instead of waiting for a status meeting, Dev and Ana pair up that afternoon and sort it out.
The Daily Scrum isn’t a report to a manager. It’s a planning conversation, among the people doing the work, about how to reach the goal.
The Sprint Review
At the end of the Sprint, the Scrum Team and stakeholders meet for the Sprint Review. People often treat this as a demo. It’s more useful as a working session.
The team shows what’s actually working. A stakeholder from customer support points out that people returning after a long gap might not recognize their “last order”. Priya adds a backlog item to show the order date more clearly. The Product Backlog changes because of real feedback, not assumptions.
The Sprint Retrospective
The last event is the Sprint Retrospective, and it’s the one most often skipped when teams are busy. That’s a pity, because it’s the only event purely about how the team works.
Marcus facilitates. The team notices that mid-Sprint scope questions kept landing in Slack threads where Priya missed them. They agree on a small change: urgent questions go in one channel she checks twice a day. It’s a small, practical adjustment, and exactly what the event is for.
The Increment
Throughout the Sprint, the team has been building toward the Increment: a usable step toward the Product Goal. Something counts as part of the Increment only when it meets the team’s Definition of Done. That might include tested, accessible, reviewed, and deployable.
That’s the discipline that makes the rest of Scrum honest. Without it, “done” means whatever each person feels it means.
The Sprint Review is where it comes together
If you step back from the example, you can see how the pieces fit. Each artifact has a commitment attached: the Product Backlog has the Product Goal, the Sprint Backlog has the Sprint Goal, and the Increment has the Definition of Done. Each commitment gives its artifact something to measure against.
The events are the moments where the team looks at those artifacts honestly and decides what to do next. That’s the whole idea behind the three pillars of Scrum: transparency, inspection, and adaptation. You make the work visible, you look at it regularly, and you change course when you need to.
Common mistakes
A few patterns I see again and again:
- Requirements handed over the wall. Analysis finishes before the Sprint, gets passed to the Developers as a spec, and the conversation stops. Refinement works better as a continuing conversation.
- The Product Owner as a note-taker. They collect requests from stakeholders and pass them to the team without making any real decisions. Scrum needs a Product Owner who orders the backlog and says no.
- The Scrum Master as a scheduler. Booking meetings isn’t the job. Coaching the team and clearing obstacles is.
- No Sprint Goal. Without one, a Sprint is just a list of tasks, and nobody can tell if it went well.
- The Daily Scrum as a status report. If the team is talking to a manager instead of each other, it has lost its purpose.
- A Sprint Review that’s a sign-off. The point is feedback, not approval.
- A weak Definition of Done. Quality gets pushed into a “hardening Sprint” later, and the Increment isn’t really usable.
- Skipping the Retrospective. The team stops improving, and the same problems keep coming back.
Practical takeaways
If you want to apply this to your own team, start small.
- Write down who decides what. If you can’t say who orders the backlog, who decides whether work is done, and who looks after the team’s way of working, start there.
- Write a real Sprint Goal. One sentence that explains why this Sprint matters. If you can’t write one, the Sprint probably isn’t focused enough.
- Make refinement of shared work. Give it a regular slot, with the Product Owner and the people who will build the item in the room.
- Check your Definition of Done. Does it describe a usable product, with acceptance criteria actually checked, or just finished coding?
- Invite one stakeholder who disagrees to your next Sprint Review.
- Pick one thing from the last Retrospective and actually do it before the next one.
Conclusion
Scrum isn’t really about meetings, boards, or terminology. It’s about creating value in small steps, looking at what actually happened, and being willing to change. The accountabilities give people clarity. The events create regular moments to pause and learn. The artifacts keep everyone looking at the same truth.
For Business Analysts, this is good news. Listening, questioning, and turning vague needs into clear, testable outcomes matter more in Scrum, not less. When the pieces work together, a team spends less time arguing about process and more time making something people want to use.