Priya's Team: Servant Leadership or Project Management?
Priya is Scrum Master for Team Borealis, a five-person team on a four-team ART. She personally keeps the team's Jira board meticulously up to date, writes acceptance criteria with the PO before refinement, assigns each story to an engineer at the daily stand-up, and asks stakeholders to route all questions through her 'so the team isn't disturbed'. The stand-up runs as a round-robin status report and reliably takes 30 minutes. Over the last three sprints the team met its iteration goal once; about 40% of committed stories carry over, and the same two engineers do most of the talking and all of the critical work. The PO has now asked Priya to take over backlog refinement as well, 'since you're already writing the acceptance criteria.' Priya also asks whether she should buy an AI assistant that drafts user stories and acceptance criteria from the PO's meeting notes.
1. Which of Priya's current behaviours fall outside the Scrum Master accountability in SAFe, and what does each one cost the team?
Read the worked answer
In SAFe the Scrum Master is a servant leader and coach: facilitating, teaching, removing impediments, fostering self-management and built-in quality. She is not a project manager, not the team's secretary, and not a second Product Owner.
- Updating the board for the team. Transparency is the team's responsibility. When the SM maintains the board, the data reflects what she believes happened, not what the team agrees happened - and the team learns that the board is reporting, not a working tool.
- Assigning stories at stand-up. Directly anti-self-management, and it concentrates work on whoever she trusts. It is also a likely cause of the 40% carry-over: assignment is not pulling.
- Writing acceptance criteria with the PO. The PO owns backlog content; the team owns how the work is done and should own the decomposition and the conversation that produces acceptance criteria. Priya is absorbing the team's refinement thinking and the PO's content authority at the same time.
- Routing all stakeholders through herself. It feels protective but it severs the team from direct feedback - exactly what the iteration review and System Demo exist to provide.
- The 30-minute stand-up is a facilitation failure, and it is also where the two dominant voices get reinforced.
Note that the pattern is coherent: she is compensating for a team that is not yet self-managing, which makes the team less self-managing.
2. Name the first three changes you would make, and give a concrete, observable signal that each is working.
Read the worked answer
Pick changes that are cheap, immediate and visible - coaching beats restructuring at this stage.
1. Stop assigning; ask. At stand-up, present the highest-priority unstarted story and ask who wants it. Nothing else changes that day. Signal: within three iterations, at least two different people volunteer for the top item, and no story sits unclaimed for a whole stand-up.
2. Hand the board back. Announce that from tomorrow the team updates its own items before stand-up, and that 'if it isn't on the board, it didn't happen.' Priya checks for gaps but does not fill them. Signal: the board's carry-over count matches what the team says at the retrospective - i.e. the data is trustworthy without her.
3. Timebox and re-shape the stand-up. Fifteen minutes, walk the board right-to-left (start with what is closest to done and what is blocked), and move every discussion offline with a named owner. Signal: stand-up consistently under 15 minutes and at least one blocker per week gets an owner and a follow-up rather than a monologue.
Underneath all three, coach the PO on refinement: the goal is the team arguing about acceptance criteria, not Priya drafting them. If the two dominant engineers are still carrying all critical work after two iterations of volunteering, that is the next retrospective topic - with the team, not for them.
3. Should Priya take over refinement, and should she buy the AI story-drafting assistant?
Read the worked answer
Treat these as one question: does it increase the team's ownership, or further remove it?
Refinement. No - taking it over makes her the de facto proxy PO and deepens the dependency she is trying to break. The right move is to help the PO prepare (a clear agenda, the top of the backlog, the decisions needed) and then get out of the way so five engineers plus the PO argue about the work.
The AI assistant. The tool is not the problem; using it to displace ownership is. AI-drafted stories and acceptance criteria are useful as a first draft that saves the PO preparation time, and dangerous as an artifact the team is handed. Guardrails:
- The PO still owns and validates every item; nothing enters the backlog unreviewed.
- The team still decomposes and estimates - estimation is where shared understanding is built, and it cannot be generated.
- Vague generated criteria ('the system should be fast') are worse than none, because they look complete.
- Check the data-handling policy before pasting customer or roadmap material into any external tool.
The test: in two iterations, is the team talking more in refinement or less? If Priya's involvement goes down and the team's goes up, both the tool and the coaching are working. If the tool lets her produce more backlog faster while the team stays quiet, it is amplifying the exact problem.