What a Team Questions Tell Us About Agile System Design

In organizations that use Kanban, teams evolve their existing practices incrementally to improve service delivery. In contrast, organizations adopting framework-based approaches like Scrum typically undergo more dramatic changes, introducing new roles, responsibilities, ceremonies, and artifacts all at once. In these Scrum environments, rapid structural changes lead to teams facing numerous challenges as they navigate the new system and new ways of working.

Beyond new roles and ceremonies, an agile transformation requires teams and leaders to adopt new operating principles and values. The questions team members ask as they figure out how to adapt indicate process gaps and reveal how well the organization is absorbing those underlying principles.

For example, a team using Jira for the first time might ask: “How do we track the progress of Epics?”

While answering the question directly is an option, a more effective response begins by analyzing why the question was asked in the first place. Instead of focusing on the mechanics of tracking Epic progress, work with people to better understand why tracking is needed and what it reveals about the broader system.

Questions Are Leading Indicators

Leadership typically evaluates agile transformations using delivery metrics such as cycle time and throughput, as well as agile maturity models. These metrics indicate the effect of new practices on team performance weeks or months after new ways of working are introduced.

The questions people ask provide real-time clues about certain aspects of the system’s health. When a team asks how to estimate an epic, they are sharing a quality of the system that might greatly determine the organization’s overall agility and would otherwise never appear on a dashboard.

Metrics dashboards do not capture team uncertainty, operational gaps, or cultural friction. Clues to these problems surface in retrospectives, daily team collaboration, and informal conversations. The questions teams ask during daily work provide immediate feedback regarding system design, organizational culture, and the adoption of agile principles.

Four Example Questions and Their Causes

1. “How should we track progress on Epics?”

• The systemic cause: The organization tracks progress through status reports on work in progress rather than on the delivery of working software. Teams are expected to generate traditional project status updates and attend progress reviews, increasing administrative overhead.
• The coaching response: The demand for epic tracking usually stems from large projects with long lead times, complex dependencies, and low trust that teams will deliver on time. Address these issues and shift the team toward demonstrating more frequent, incremental delivery. Teams are freed from manual status reporting when they can instead regularly showcase deployed software.

2. “How do we track individual effort and capacity?”

• The systemic cause: This echos the factory-era when workers were interchangeable units of labour and each person would have their outputs measured. It surfaces wherever people are planned and budgeted as resources — central planners assign named individuals, performance management rewards utilization.
• The coaching response: Move budgeting, planning and measurement to the team, and forecast using the team’s own delivery history. Fixed capacity planning supports teams with stable team membership.

3. “How should we estimate this work?”

• The systemic cause: Teams rely on estimation because delivery schedules are unpredictable. Estimates are frequently used to measure team velocity, track individual capacity, or prove that a team is fully utilized.
• The coaching response: Teams are better off not estimating work. Instead of estimates, a better place to focus would be on the flow of work, handoffs, and understanding what causes delays. Reduce wait times to establish predictable cycle times. Shift team focus away from upfront estimation and toward tracking lead time and delay.

4. “Who is supposed to write the user stories?”

• The systemic cause: User stories are treated as formal, static requirement documents handed off between roles. Teams collaborate on user stories based on rigid responsibility matrices, reinforcing a siloed interaction model.
• The coaching response: Reframe user stories as the product of team discussions about what users might want. Those discussions build a shared understanding across perspectives about which customer problems to solve and what needs to be built. The story artifact is simply record, the note, that best supports that process and captures its outcomes.

How Coaches and Leaders Should Respond

When teams ask operational questions, organizations that favor consistency and standardization often respond by creating new rules, templates, or procedures. While this provides an immediate answer and supports consistency, rushing to standardize directly undermines agility. Standardization freezes the current way of working into policy, making future adaptation harder, slower, and subject to governance approval:

• Context is ignored: Standards assumes every team operates under the same conditions, and that a single standard will have the same impact.
• Learning is minimized: When people follow prescribed process they don’t learn for themselves. When teams don’t learn, they don’t develop the capability to solve their own problems in the future.
• Rigidity increases: Processes become difficult to adjust once codified into official standards, sacrificing adaptability for uniformity.

When asked operational questions, refrain from handing out a standardized set of instructions. Instead, apply the following four-step coaching approach:

1. Analyze the root cause before prescribing solutions

When a team brings an operational request, avoid jumping straight to a solution. Questions usually arrive as fixed conclusions, “How do we do X?” which are often several steps removed from the real issue. Take time to explore what environmental pressures, policies, or trust gaps prompted the question in the first place, so you help people solve the actual problem rather than add another workaround or band-aid.

To make the systemic context visible, sketch a problem tree or lightweight systems map together. Trace how the question connects to the workflow, handoffs, stakeholders, or other processes related to the request.

2. Guide with principles rather than fixed recipes

Agility relies on teams developing their own problem-solving capability. When teams ask a question, instead of prescribing a direct answer, offer a relevant principle or story to help them decide for themselves. This approach helps teams build judgment and make context-appropriate choices more independently.

Capture the question or challenge, capture what they want to happen as a result, identify what Agile principles or values are relevant, and lastly think of what a solution that aligns with those principles might look like.

3. Watch for recurring patterns

Distinguish between isolated questions and recurring organizational themes. A single question from one team often reflects local curiosity or learning. However, when the same question appears across multiple teams, it indicates a structural constraint in the organization’s design, governance, or culture.

A Question Log can serve as a lightweight diagnostic tool. Tracking recurring topics across teams and reviewing them periodically helps you identify systemic trends. This data enables you to address broad organizational constraints with leadership rather than treating the same symptom repeatedly at the team level.

Agile transformations are typically measured by what teams produce. However, analyzing the questions teams repeatedly ask provides an earlier, more accurate diagnostic of organizational design and systemic health.