Day Six, Nothing Accepted

Iteration scope is the PO's call, and 'small and quick' is the most expensive phrase in a backlog. On Day 6, with 6 of 42 points done, any insertion costs far more than its estimate: it forces a re-plan, adds a fourth context switch to people already juggling three features, and lands on a team that is not finishing what it started.

So do not simply refuse - interrogate the deadline. Two questions: what is the audit date, and what does the auditor actually need to see? Often the answer is evidence of a control that partly exists, or a documented plan, not shipped software.

Then choose:

• If genuinely date-driven and hard: find the cheapest form of compliance - a configuration change, a documented control, a manual process behind a flag - rather than a product story.
• If it must be built: trade explicitly. The team removes equivalent points from the iteration, the PM agrees which story defers, and the team consents in standup, not in a side channel.
• If neither: pull it to the top of the next iteration and confirm in writing with the audit owner.

The trap is saying yes to preserve the relationship, or no on principle. The correct answer is a visible trade with the date and the required evidence made explicit.

Treat the three situations differently, because they have different owners and different clocks.

Pricing story - the premise is invalid. The estimate was built on an assumption that has just been disproved, so the estimate is void. Stop it and split: (a) a one-to-two day spike to answer the specific question - which service, what interface, what does the contract look like, what is the migration cost; (b) the implementation, re-estimated next iteration. Return the points to the backlog and remove it from 'in progress'. An unestimated story sitting in progress is fiction that the burn-down will report as fact.

Blocked stories - a Day 6 block is an ART issue. Give the RTE the block, the owning team, and a needed-by date, and ask for a daily unblock cadence. If it will not clear this iteration, pull the stories, tell the PM, and record it against the PI objective it threatens. That is not a team embarrassment; it is the dependency system working.

Communicate at the next ART sync with the honest picture and the options you are considering.

The trap is leaving the pricing story open so the burn-down looks less alarming. That converts a schedule problem into a data problem, and everyone else plans on the data.

Fourteen in progress and zero accepted is a flow problem, not an effort problem. The symptoms point to no WIP discipline, work started to demonstrate activity, three features in flight per person, and acceptance batched at iteration end - which is also why the pricing story's bad assumption surfaced so late.

Changes for the next iteration:

1. WIP limits per column (start around 8 in progress for a team of eight) and swarm on the oldest item. 'Stop starting, start finishing.'
2. Limit features in flight to one per pair of developers; the PO sequences the backlog to make that physically possible.
3. Smaller stories with acceptance criteria visible at kickoff, so a wrong assumption is caught in hours rather than days.
4. Accept stories as they finish, not in a batch at the end.
5. Bring data to the retrospective - cycle time, cumulative flow, the 6-of-42 burn-down - and ask what caused items to start and not finish. The usual answers are interruptions and unclear criteria, both of which you can act on.

The trap is responding with exhortation or more ceremony. Change the queue and the batch size, and let the team be judged against a 42-point plan while doing so.