3.2 Prompt Design Patterns & Techniques

3.2 Prompt Design Patterns and Techniques

Core principle: Choose the lightest prompt pattern that makes the work inspectable. Patterns can improve relevance and consistency; none makes an output deterministic, truthful, secure, or authoritative by itself.

---

Zero-Shot and Few-Shot

A zero-shot prompt gives an instruction without showing an example. It is often sufficient for simple transformation, brainstorming, or summarization when the desired form is familiar. A few-shot prompt includes a small number of carefully selected input-output examples in the current context. Examples can improve adherence to a local schema or tone without updating the model's weights.

For Product Backlog work, a few-shot prompt might include two well-written examples of the team's acceptance-criteria style followed by a new, sanitized requirement. Examples can also introduce mistakes or bias, so they should be representative, policy-compliant, and reviewed. Neither approach guarantees factual accuracy.

Decompose Complex Tasks and Ask for Evidence

For a complicated item, request a structured analysis rather than hidden reasoning: identify assumptions, list dependencies and risks, cite the supplied source, compare alternatives, and give a concise rationale. Breaking the work into stages lets a person inspect each intermediate result. It is safer than treating “think step by step” as a magic switch or asking the model to reveal private chain-of-thought.

Example:

Using only the supplied architecture note and Definition of Done:
1. List assumptions that require confirmation.
2. Identify dependencies and test risks for this Product Backlog item.
3. Propose two vertical-slice options with trade-offs.
4. Cite the source paragraph supporting each claim.
5. End with questions for the Developers; do not estimate or select work for them.

The output is still a hypothesis. A fluent rationale can rationalize a false premise, and asking the same model to critique itself is not independent verification. Compare claims with source documents, tests, tools, or qualified people.

Role and Perspective Framing

A role instruction can direct attention: “Review this from an accessibility tester's perspective” or “suggest neutral questions a conflict facilitator might ask.” It does not make the model certified, experienced, or unbiased. Ask for multiple perspectives when a single persona could narrow the answer.

Scrum.org's preparation page curates Six Thinking Hats as an additional resource. The hats are an optional divergent-thinking lens: factual information, feelings, caution, benefits, creative alternatives, and process control. A Scrum Master might invite the model to generate questions from each lens before a difficult decision. The team decides whether those questions are relevant; the technique is not part of Scrum and does not add an event.

Constraints and Delimiters

Positive constraints state what the output must do; negative constraints state what it must avoid. Prefer specific, testable boundaries such as “use only the supplied facts,” “list unknowns,” or “return at most three options” over dramatic capitalized commands. When a Product Backlog item contains untrusted text, quote or tag it as data. Delimiters such as XML tags, Markdown headings, or fenced blocks can make roles and regions clearer.

Delimiters do not neutralize prompt injection. A retrieved document can contain malicious instructions, and a model may still follow them. Robust designs separate trusted instructions from untrusted data, minimize tool permissions, validate outputs, require confirmation for consequential actions, and test adversarial cases.

Optional Team Practices Are Not Scrum Rules

A team may use a Definition of Ready, INVEST, Gherkin, DORA measures, or a local prompt template. These can be useful practices, but the Scrum Guide does not define them. A prompt can compare an item with a team-authored readiness checklist only if the response labels it as that team's practice. It should not claim the Product Owner or Scrum Master must approve readiness before Developers may discuss an item.

Pattern Selection

• Use zero-shot for a simple, low-risk transformation.
• Add few-shot examples when local form and terminology matter.
• Decompose work when errors could cascade or intermediate evidence can be inspected.
• Add perspectives to explore blind spots without inventing expertise.
• Add constraints and delimiters for focus and clarity, then maintain real security controls.
• Use multiple lenses, such as Six Thinking Hats, for exploration; preserve direct collaboration and human judgment.

Compare Patterns Empirically

For a recurring task, keep a small test set and compare zero-shot, examples, decomposition, and retrieval on the same evidence. Record source accuracy, format validity, correction effort, latency, and cost. Select the simplest pattern that meets the need; a more elaborate prompt is not automatically better.