Two Product Owners and a Team Lead
A 14-person group is called a Scrum Team: one Product Owner, one Scrum Master, twelve Developers. In practice: a business analyst writes all Product Backlog items and the Product Owner appears only at the Sprint Review to accept or reject work. A tech lead opens a chat thread at 09:00 each day, lists who works on what, and each Developer replies 'done / doing / blocked' to him. The Scrum Master chairs that thread for 20 minutes. Sprint Goals are written as 'complete PBIs 101–118'. Two stakeholders regularly message Developers directly mid-Sprint and get work done. Sprints are three weeks.
1. For each of the four practices - the business analyst writing items, the Product Owner appearing only at Review, the tech lead allocating work, Developers reporting to the tech lead - identify which accountability is misplaced and where it belongs.
Read the worked answer
| Practice | What is actually happening | Accountability in Scrum |
|---|---|---|
| BA writes all Product Backlog items | Ownership of content and ordering is delegated to a non-accountable person | The Product Owner is accountable for the Product Backlog - its content, availability and ordering. Eliciting input is fine; delegating the decision is not. The PO may take advice from anyone, but cannot hand over the accountability. |
| PO only at Sprint Review | PO becomes an acceptance gate at the end | The PO is accountable for maximising value throughout the Sprint: ordering, clarity, availability to Developers, and deciding trade-offs. Arriving at Review to accept or reject means the team builds on assumptions for three weeks. |
| Tech lead allocates work | Work assignment by an individual | Developers self-manage: they decide who does what, how, and how the work is decomposed. Allocation by title is a command-and-control residue. |
| Developers report to the tech lead | Status flow upward to a non-accountable person | The Daily Scrum is for Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog - a planning event, not a reporting event. |
The pattern, not just the instances: every practice routes a Developers' or Product Owner's decision through an intermediary who holds no Scrum accountability but holds de facto authority. Accountability and authority have been separated. That is the diagnosis, and it is why each fix looks small individually but nothing changes if only one is fixed.
2. Sprint Goals are written as 'complete PBIs 101–118'. Explain why that form removes the flexibility a Sprint Goal is supposed to create, and rewrite the pattern.
Read the worked answer
A list-of-items Sprint Goal is a scope commitment disguised as an objective. Two consequences follow:
- No room to negotiate. If item 104 turns out to be twice the size, the only options are 'miss the goal' or 'work overtime'. A genuine Sprint Goal states a purpose, so the Developers and Product Owner can trade scope against purpose as they learn - the flexibility Scrum deliberately builds in.
- No shared objective. Eight Developers with eight tickets have eight goals. The Sprint Goal is the single objective that lets them coordinate without a tech lead assigning work; the ticket list removes the reason for them to self-manage.
Rewrite pattern: 'By the end of this Sprint, [user or business outcome] is achievable, verified by [evidence].' Example: 'By the sprint's end, a returning customer can reset a password and complete checkout without contacting support, demonstrated end to end on the staging environment.'
Test to apply when reviewing a Sprint Goal: can a Developer, asked what the team is achieving this Sprint, answer in one sentence that contains no ticket numbers? If not, it is a scope list.
3. As Scrum Master, what is your first intervention with the tech lead, and what outcome are you aiming for?
Read the worked answer
What not to do: do not tell the tech lead to stop assigning work and leave it there. That produces a power vacuum, Developers who have never practised self-management seize up, and the tech lead concludes Scrum is naive. The tech lead is usually filling a real gap - the team has no shared plan - so remove the gap, then the behaviour.
A workable sequence:
- Talk to the tech lead privately first, with a question, not a correction. What does he think happens if he is on leave for three days? The aim is for him to name the dependency himself.
- Change the forum before changing the person. Coach the Developers to own the Daily Scrum: they select topics, the tech lead contributes as a Developer. Once they plan in the event, allocation has nowhere to happen.
- Make self-management concrete, not rhetorical. Ask the Developers to pick the top item and split it themselves in Sprint Planning. Early successes are the only thing that convinces a sceptical tech lead.
- Recruit him. He has the technical judgement the team needs. Positioning him as the person who makes self-management work - not the person it replaces - is usually the difference between adoption and quiet reversion.
Goal state: the tech lead is still a Developer with influence; the difference is that the plan is produced in the events, visible to all, and owned by the Developers. Success is measurable: on a day the tech lead is absent, the Developers still re-plan without asking anyone.