Expert User Access Agile Development Workflow Guide

Secure a real expert user, keep a continuous question channel open, and turn their feedback into requirement, priority and plan changes.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

Easy access to expert users is one of the properties Crystal treats as core. For background on the framework itself, see the Crystal Agile Framework method page. This page is about doing one thing well: getting a person who really uses the system into the daily flow of development, and making sure what they say changes what the team builds.

Cockburn's own presentation of Crystal lists easy access to expert users alongside frequent delivery and reflection, and the Wikiversity summary of Crystal describes the practice concretely: developers work with an expert in the project area who answers questions and suggests solutions. Two conditions follow from that description. The expert must be a real user of the domain, and the relationship must be working contact rather than a formal sign-off.

The same Wikiversity source is explicit that the expert should be an actual, real-life user, not a tester from the development team. A tester can check whether software matches a specification, but only a real user can tell you whether the specification matches the work. That distinction is the most common place teams quietly compromise.

Practitioner guidance also frames access as continuous. Agile3 lists Crystal's properties as fundamental rather than optional, and describes expert access as direct and ongoing. A single requirements interview at kickoff does not meet the bar. Assumptions about user behaviour pile up every week, and each one is cheaper to test the day it is made than the month it ships.

Finally, the point of access is change. One Crystal overview labels the practice as improvement based on experts, which puts the emphasis on what happens after the expert speaks. If answers sit in chat history and never alter a backlog item, acceptance criterion or plan, the team has the ritual without the benefit.

For a product manager, the skill has three parts: choosing and securing the right person, designing a channel developers will actually use, and closing the loop so expert input reaches decisions. The steps below cover each, along with the failure signals that tell you access has decayed.

How It Works

The practice runs as a loop between the team and the expert user. Developers send two kinds of material to the expert: questions and working software. The expert sends back answers, suggested solutions and judgements on whether the team's assumptions hold. The team then turns that return traffic into concrete changes.

flowchart LR
  A[Developer questions] --> C[Expert user]
  B[Working features] --> C
  C --> D[Answers and suggestions]
  C --> E[Validated or rejected assumptions]
  C --> F[Feature feedback]
  D --> G[Plan refinements]
  E --> G
  F --> G
  G --> H[Next iteration]
  H --> A
  H --> B

Inputs. Useful inputs to the expert-access workflow include the expert's real-user experience and domain knowledge, developers' questions, proposed requirements, assumptions about user behaviour, and working or integrated features, as described across Agile3's Crystal guide and the Wikiversity summary. The last input matters most. Wikiversity notes that greater hands-on involvement with the system gives the expert more relevant experience to base feedback on, so an expert who only reads specs gives weaker feedback than one who uses the build.

Outputs. Typical outputs are clarified requirements, expert answers, suggested solutions, rapid feature feedback, validated or rejected assumptions, and refinements to the product or development plan, per Wikiversity. Each output should land somewhere specific: a clarified requirement updates an acceptance criterion, a rejected assumption kills or reshapes a backlog item, and a suggested solution becomes a candidate for the next slice.

Where it sits in the cycle. Agile3 describes the Crystal Clear workflow as a small co-located team making a high-level plan, then running iterative design, coding, testing and integration, delivering working software and holding reflection workshops. Expert access threads through all of it. During design and coding it answers questions. After integration it tests features against real use. In reflection, the team reviews whether the channel itself is working.

Why continuity beats volume. The value of the loop comes from short latency, not long sessions. A developer who waits days for an answer either stalls or guesses, and guesses harden into code. Frequent, small exchanges keep the cost of a wrong assumption low. That is why the practice is described as regular, direct access rather than a scheduled review.

How you can tell it is working. Developers name the expert when asked who decides a domain question. Recent backlog changes trace back to expert input. The expert has touched the current build. If any of these fail, the loop has broken somewhere, and the steps below show where to repair it.

Step-by-Step Guide

Step 1: Map the domain questions the team cannot answer

Before looking for a person, list the decisions developers keep escalating or guessing at: workflow order, edge cases, terminology, what users do when something fails. Group them by domain area so you know what expertise you need. This list becomes the brief you use to recruit the expert and the first agenda for working with them. It also gives you a baseline, because you can later check whether these questions now get answered quickly.

Pro tip: Pull the list from recent code review comments and stalled tickets, where guesses are easiest to spot.

Step 2: Choose an actual user as the expert

Select someone who does the work the software supports, not a proxy. Crystal guidance says the expert should be a real-life user rather than a tester from the development team. A business analyst or internal QA lead can help, but they cannot replace first-hand experience of the job. Prefer someone respected by peers, since their answers will need to hold when the software reaches the wider user base.

Pro tip: If two candidates are close, pick the one who is willing to use rough, unfinished builds.

Step 3: Secure time and agree on the access channel

Negotiate a standing commitment with the expert's manager, framed as part of their job rather than a favour. Agree on how developers reach the expert, for example a shared channel for quick questions plus one short working session each week. Set an expected response window so developers know whether to wait or proceed. Write the arrangement down so it survives reprioritisation in the expert's department.

Pro tip: Ask for a small, regular slice of time rather than large occasional blocks; latency matters more than total hours.

Step 4: Let developers ask directly

Route questions from developers straight to the expert instead of funnelling everything through the product manager. Direct contact matches Crystal's description of developers working with the expert, who answers questions and suggests solutions. The product manager stays informed by reading the shared channel, not by acting as a relay. Relays add delay and strip out the context that makes an answer useful.

Step 5: Put working features in the expert's hands

At each integration point, give the expert access to the running build and ask them to do real tasks with it. Hands-on use yields more relevant feedback than reviewing descriptions. Watch where they hesitate, work around the software or reach for another tool. Capture those moments as feedback items with enough detail for a developer to act on.

Pro tip: Give the expert a realistic task from their own week, not a scripted demo path.

Step 6: Log answers and assumption checks

Keep a lightweight record of each significant answer, the question it resolved, and any assumption it confirmed or rejected. This turns chat traffic into a durable decision history. It also shows patterns, such as a domain area where the team keeps being wrong. Without the log, the same question gets asked again by the next developer and the expert's patience erodes.

Step 7: Turn feedback into plan changes

Review expert input when you set priorities for the next cycle and make the resulting changes explicit: updated acceptance criteria, dropped items, new slices. This is the step that makes the practice improvement based on experts rather than consultation. Tell the expert what changed because of their input, since visible impact keeps them engaged. If a cycle passes with no expert-driven change, treat that as a warning sign.

Pro tip: Tag backlog items changed by expert input so you can count them at the next reflection.

Step 8: Review the channel in reflection workshops

Use the team's reflection workshop to examine how the expert collaboration is working. Agile3 describes these workshops as the place to look at what worked, what did not, and how to improve collaboration and feedback. Ask whether answers arrived fast enough, whether the expert saw the latest build and whether their input changed anything. Agree one concrete adjustment and try it in the next cycle.

Best Practices

• Recruit for first-hand experience over seniority. A manager who used to do the job may describe how it should work, while a current practitioner knows how it actually works, and the gap between the two is where requirements go wrong.
• Treat access as a channel, not a meeting. Crystal practitioner guidance describes direct and continuous access, so design for quick questions answered the same day, with scheduled sessions as a supplement.
• Show the expert software, not slides. Feedback on a running build reflects real use, and hands-on involvement produces more relevant feedback than reviewing mockups or documents.
• Write down the assumptions you are testing before each session. Stating the assumption in advance makes it clear whether the expert confirmed or rejected it, and stops the team from reinterpreting ambiguous feedback in its own favour.
• Close the loop visibly. Tell the expert which changes came from their input; people who see their answers shape the product keep answering, while people who see no effect drift away.
• Protect the expert's time. Batch low-urgency questions and keep sessions short, because an overloaded expert starts giving rushed answers or stops responding.

Common Mistakes

• Using an internal tester or QA lead as the expert user.: Crystal guidance says not to substitute a development-team tester for a real user. Keep testers in their role and recruit someone who does the actual work the software supports.
• Treating expert access as a one-time requirements interview at kickoff.: Practitioner descriptions characterise access as regular and continuous, not optional or occasional. Set up a standing channel so assumptions made mid-project get checked while they are still cheap to change.
• Funnelling every developer question through the product manager.: Relaying adds delay and loses context. Let developers ask the expert directly and have the product manager follow the shared channel to stay informed.
• Collecting expert feedback that never changes the backlog.: The practice is described as improvement based on experts, so each cycle should show explicit changes traced to expert input. If none appear, review the feedback log and the prioritisation step.
• Asking the expert to judge descriptions instead of working software.: Give the expert the running build and real tasks to perform. Feedback on documents reflects imagined use and misses the friction that only appears when someone actually does the job.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Crystal Agile Framework

Related Skills

• Selecting the Right Crystal Color Variant for Your Team
• Implementing Frequent Delivery Cycles in Crystal Projects
• Designing Technical Environments That Support Team Focus
• Facilitating Osmotic Communication in Agile Teams
• Tailoring Agile Processes to Your Specific Team Context
• Establishing Personal Safety for Honest Team Collaboration
• Running Reflective Improvement Workshops in Crystal

Sources

• Crystal Methods - Wikiversity
• Crystal Methodology | PPTX - Slideshare

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.