Day 6 on Team Cinder: A Four-Day Blocker and an Empty Testing Column
It is day 6 of a 10-day iteration on Team Cinder: five engineers, one PO, plus a shared UX designer. The board shows four stories in 'in progress'. Story C-142 has been blocked for four days waiting on a vendor API contract; it has been mentioned at stand-up every morning but nobody has escalated it. The stand-up takes 25 minutes and has become a status round for the PO. Two integration defects were found yesterday, and the tech lead wants to log them as 'known issues' and carry them into the next PI so the iteration goal isn't at risk. One engineer proposes pulling a sixth story because 'the board looks empty in testing'. This is the team's second iteration on the ART and it has not yet attended an ART Sync.
1. What is the Scrum Master seeing here, and what are the three moves for this week?
Read the worked answer
What the SM is seeing. This is a flow and escalation failure, not a motivation problem.
- Four stories in progress on five people with an empty testing column is a classic push system: start more, finish less. Pulling a sixth story would make it worse.
- A four-day blocker mentioned every morning and escalated never means the impediment path does not exist. Repetition at stand-up is being mistaken for escalation.
- A 25-minute PO status round means the stand-up has stopped being the team's event.
- 'Known issues' is quality being traded for a green iteration goal.
Three moves this week:
- Escalate C-142 today. Named owner, named vendor contact, named date by which the team needs the contract. Take it to ART Sync/SoS immediately; if it cannot be resolved inside the ART, it goes to the RTE. Log it in the impediment backlog so its age is visible.
- Stop starting, start finishing. Enforce WIP limits: no sixth story. Swarm the blocker or the oldest item awaiting verification. The empty testing column is a signal to help, not to add work.
- Fix the stand-up. Fifteen minutes, walk the board right-to-left, everyone answers to the team and not to the PO, and anything needing discussion goes offline with an owner. Coach the PO separately about where status questions belong - refinement and the iteration review, not the daily.
2. The 'known issues' proposal. How do you respond?
Read the worked answer
The instinct is understandable - the iteration goal is at risk - but the move converts a two-day problem into a cross-PI problem, and it does so in a system five other teams depend on.
The SM's position: built-in quality is not a phase you can defer. Defects carried as 'known issues' accumulate as technical debt, break the System Demo, and eventually slow the whole train. The label itself is the dangerous part: once a category exists for shipping known defects, it fills up.
But it is not the SM's call to make alone. The PO owns the scope trade-off. The SM's job is to make the cost visible so the PO can decide:
- What is the actual fix effort - hours or days? Often it is smaller than the disruption of deferring.
- Do these defects touch a shared interface or block another team's testing?
- Do they prevent the feature being demonstrated at the System Demo?
- Is the IP iteration available as a deliberate, planned home for the fix rather than an open-ended carry-over?
A reasonable landing: fix now if the effort is small; otherwise schedule the fix explicitly into the IP iteration with owners and dates, record it as planned debt. And correct the framing with the team: the iteration goal is not met by moving quality out of it. If the goal is genuinely unreachable, saying so at the iteration review is the honest outcome the ART can act on.
3. The team wants to skip ART Sync, and wants to let an AI coding assistant generate the integration tests without human review 'because AI wrote it'. Address both.
Read the worked answer
ART Sync. Skipping it in the team's second iteration - with an unresolved vendor blocker and fresh cross-team integration defects - is exactly the wrong moment. ART Sync (Scrum of Scrums plus PO Sync) is where dependencies and impediments become visible to people who can act on them. C-142 has already shown what happens when escalation is local: nothing.
If the 45 minutes feels like a waste, that is a facilitation problem to solve with the RTE - send one engineer and the PO rather than the whole team, bring a dependency list rather than open discussion, and push for it to be about cross-team items only. Skipping is not on the table; making it useful is.
AI-generated tests. Built-in quality practices - continuous integration, test-first, peer review, agreed standards - do not care who or what authored the code. Everything that enters the codebase is the team's responsibility and carries the team's name. Unreviewed AI-generated integration tests are worse than no tests, because they create false confidence in the exact place the team is already weak.
Guardrails: use the assistant to draft, then a human verifies that each test actually asserts the behaviour and would fail when it should; keep the definition of done unchanged; check the tool's data-handling and licensing policy before feeding it proprietary interfaces. The SM's question is always the same: does this make the team's quality more visible, or less?