Contextual refinement

How your approach adapts to the environment you’re in

Introduction: Why this article?

Agile training and theory often present refinement as a conversation about value, scope, and acceptance criteria. Technical design, according to this view, belongs in the sprint. But in practice, that doesn’t always work.

This article shows that the way you approach refinement strongly depends on the context you operate in. In enterprise environments — where regulation, dependencies, and scalability play a major role — technical detailing before the sprint is often essential. Refinement then becomes a shared design activity where the team takes active ownership of technical elaboration alongside the functional discussion.

What agile theory usually recommends about refinement

According to widely used agile guidelines, refinement is meant to make user stories understandable and small. You discuss value, acceptance criteria, and dependencies. But technical details? Those come later.

• “The team decides during the sprint how to build it.”
• “Architecture emerges over time.”
• “Refinement is not a design phase.”

Based on sources such as the Scrum Guide 2020, SAFe 6.0, XP Explained, and User Story Mapping by Jeff Patton.

Our approach: refinement as a design responsibility

In our practice, we work differently. Yes, there is a high-level design. Yes, there are architectural guidelines. But the team itself takes responsibility for the technical elaboration of work items. And they don’t wait until the sprint to do that — it happens during refinement.

What that looks like in practice:

• We discuss not only the functional question, but also the technical solution direction
• We think through error handling, logging, interfaces, and performance
• We document technical considerations or sketch component interactions (e.g. as short design notes or comments attached to the work item)
• We validate the proposed approach against the pre-established architecture guidelines

A practical working pattern:

1. The PO or architect introduces the backlog item, providing clarity on what and why.
2. Two engineers collaborate outside of the refinement sessions to technically elaborate the item, including its design and task breakdown.
3. The engineers present their elaboration in the next refinement meeting; the team addresses questions and builds a shared understanding.
4. Finally, the team estimates the item, often using Planning Poker with the Fibonacci scale. The goal isn’t precise prediction, but to surface insight differences: why do you say 3 and someone else says 12? That conversation matters more than the number.

Only when an item is functionally and technically well-elaborated do we add it to the sprint backlog — not for control, but to create room for flow and focus.

Context isn’t a footnote — it’s the foundation

“Have you included enough of the broader context… What should they optimize for: development time, reuse, performance?” — Atomic Object, A Simplified Checklist for Technical Backlog Refinement

“As a tech lead… I need to ensure they have enough information to do their jobs well, without distracting them with irrelevant details or dictating.” — Atomic Object

These quotes emphasize how context shapes the way refinement should be practiced. In some environments, speed and creativity matter more than predictability. In others — like regulated enterprise settings — clarity, risk assessment, and technical alignment are essential.

Get Johan Vink’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Agile frameworks often present themselves as context-neutral, as if the same approach applies everywhere. But refinement is inherently context-sensitive. What works in a startup doesn’t automatically apply to a bank, a government agency, or a core system environment.

In enterprise settings, refinement is more than a discussion about user needs. It becomes a preparatory design activity. This enables teams to deliver within architectural boundaries — while maintaining quality, predictability, and traceability. Not because “the architect said so”, but because the context demands it.

What this approach delivers in practice

• Teams maintain ownership: they shape the design
• Refinement reduces surprises during the sprint
• The team can immediately execute the work items
• Architectural principles are honored without central command
• The quality of delivered solutions increases

This approach aligns naturally with slice-based delivery: you incrementally build toward a larger solution, but every slice is prepared, testable, and potentially shippable.

Practical tips

The Definition of Done provides a key reference point. During refinement, the team assesses each work item against this definition to ensure the right tasks, quality checks, and agreements are in place. They also regularly revise the Definition of Done when insights emerge — removing outdated tasks or adding new ones as needed.

• Apply a clear Definition of Ready, including technical detailing
• Ensure refinement sessions actively give engineers space to raise technical questions, solution directions, and dependencies (even though refinement is formally a team-wide activity, it often leans too heavily on functional aspects in practice)
• Let teams document their own technical notes per work item, for example: “Reuse existing CustomerService to fetch customer data.”
• Capture design decisions briefly — consider C4 models, UML-lite diagrams, ADRs (Architectural Decision Records), or a simple sketch in the pull request
• Use design spikes when more technical investigation is needed upfront
• Leverage the Definition of Done as a refinement checklist: are all quality and compliance tasks covered?
• Review and evolve the Definition of Done regularly to reflect new insights

In closing: agile maturity avoids dogma

Refinement is not an end in itself. But when it results in clear, actionable, and technically sound work items, it greatly supports teams. It fosters calm, rhythm, and predictability within the sprint — crucial for teams operating in complex or regulated environments.

“Agile is not a method, but a mindset. And that mindset means understanding context, recognizing patterns, and consciously deviating when the situation calls for it. Refinement is a perfect example.”