3.3 Prompt Chaining & Multi-Turn Conversations

3.3 Prompt Chaining and Multi-Turn Conversations

Core principle: Break a complex AI-assisted workflow into bounded stages when intermediate evidence can be inspected or errors could cascade. Chaining is a design option, not a Scrum requirement, and automation authority should match risk.

---

Why Chain Prompts

A single request to decompose a large product idea, draft dozens of Product Backlog items, generate acceptance criteria, write tests, and plan implementation makes it difficult to see where an unsupported assumption entered. A chain separates concerns. For example:

1. Extract goals, constraints, unknowns, and source citations.
2. Propose a small set of vertical-slice hypotheses.
3. After inspection, draft examples or acceptance criteria for one selected hypothesis.
4. After another check, generate test ideas or a prototype.

The next stage receives only the accepted artifact and relevant sources. A checkpoint is useful when the next step could amplify an error, expose data, spend money, change production, or influence people. A low-risk spelling cleanup may run automatically; a customer-impacting decision needs stronger evidence and authorization. Scrum does not mandate a human click after every model call, but the people in the Scrum Team retain their accountabilities.

Critique Is Not Independent Verification

A draft-critique-revise loop can surface omissions. Ask the model to compare a Sprint Goal candidate with an explicit criterion, list counterexamples, or state which claims lack supplied evidence. However, the same model may preserve its original misconception or produce a persuasive rationalization. Verify important claims with primary sources, deterministic tools, tests, observed product behavior, or qualified independent review.

A useful chain for a Sprint Goal stops before selection:

Stage 1: Extract the Product Goal, candidate work, constraints, and unknowns from the supplied material. Cite each source.
Checkpoint: Scrum Team corrects the extracted facts.
Stage 2: Draft three coherent Sprint Goal alternatives with trade-offs and assumptions.
Checkpoint: The Scrum Team discusses and defines the Sprint Goal.

The model does not commit the Developers to scope, and the Product Owner does not validate the goal alone.

Instruction Hierarchy Varies

Some APIs expose system, developer, tool, assistant, and user messages; other products expose fewer or differently named layers. Retrieved documents are usually context, not inherently trusted instructions. Verify the product's documented hierarchy and keep trusted application rules separate from untrusted text. Limit tools and data access so a successful prompt injection cannot perform an unrestricted action.

Multi-Turn State and Drift

Conversation history can be useful memory, but it can also accumulate rejected drafts, stale facts, contradictions, and sensitive data. There is no universal turn count at which a conversation fails. Monitor for symptoms: forgotten constraints, references to superseded decisions, irrelevant replies, or an approaching product-specific context limit.

At a meaningful milestone, create a human-checked state record containing current decisions, sources, unresolved questions, and data restrictions. A new focused session can use that record instead of the full transcript. Treat a model-generated summary as another draft to verify because it may omit precisely the disputed fact.

Rapid Prototyping as Learning

Scrum.org's preparation page curates a rapid-prototyping resource. AI can turn a hypothesis into a mock interface or disposable code quickly enough to gather feedback. Speed does not make a prototype a Done Increment. Mark synthetic or incomplete behavior, avoid real confidential data, test the key assumption with users or stakeholders, and either discard the prototype or bring production work through the team's Definition of Done. The value is faster learning, not a shortcut around security, accessibility, maintainability, or product evidence.

Practical Controls

• Pass only accepted intermediate artifacts downstream.
• Record source version and assumptions with each artifact.
• Keep consequential actions behind explicit authorization and bounded permissions.
• Test error and recovery paths, including malicious retrieved content.
• Stop or reset when the context becomes stale or contradictory.
• Measure whether the chain improves a real outcome; additional stages can also add latency and complexity.

Chain Security

Validate the handoff schema between stages and carry forward provenance, permissions, and data classifications. Do not let a text draft silently become a tool instruction. A chain can make failure easier to locate, but more stages also create more interfaces, logging, privacy, and recovery obligations.

Operational Evidence

Instrument the chain so the team can see which source, model or tool version, prompt stage, validator, and permission produced each artifact. Traceability supports debugging and safe rollback. It should be proportionate: do not retain private content indefinitely merely to make every low-risk draft reproducible.