The Goal
The goal of pre-production is a backlog of well-defined development tasks. In Scrum this is the definition of ready. A ready task:
- Has a well-defined scope, written as acceptance criteria (the task’s own requirements, not the project’s)
- Has been discussed within the team
- Has input from stakeholders, other teams and subject matter experts
- Has been estimated, and is small enough to finish in one sprint
Why Not Just Start Coding?
Jumping straight into code has real advantages: fast progress, something to show, and less paperwork. It can be the right call for simple systems, small organizations, fast-moving markets or very experienced teams. For complex systems, larger organizations or less experienced teams, skipping pre-production usually means building the wrong thing, then building it again.
Pre-production is often the messiest phase in an organization and the least professionalized, while production, running standard Scrum, is the cleanest. That gap is exactly why pre-production deserves the most attention.
Iterate, Don’t Do It All at Once
First ask: does the team understand the goals of the project as a whole? If not, do high-level pre-production first: requirements, high-level use cases, and a low-detail feature list. Then work feature by feature, in batches: low-level use cases, detailed features, the technologies involved, and finally tasks. Each batch flows into production while the next is being prepared.
Same Scope, Different Views
Different people look at the same scope through different lenses:
| View of scope | Requirements | Use cases | Features | Technologies | Epics, tasks and bugs |
|---|---|---|---|---|---|
| Main viewer | Customer and contract | End users | Product stakeholders | Technical stakeholders | Development team |
| Validated by | Acceptance test procedures | Playtesting | Test cases | Test code | Task testing guidelines |
| Problems show up as | Customer defect reports | Design flaws and feature gaps | New bugs | Expanding tasks | Failed tests |
There is no simple one-to-one mapping between these views, but you can keep traceability between them, so every requirement can be traced to the features and tasks that meet it, and validated at the end.
The UX Design Process
UX design helps production directly. It clarifies requirements before they surprise the team, reveals edge cases the customer didn’t think to ask for, produces a blueprint for development (flows, mockups, prototypes and user feedback), and solves problems cheaply in low-fidelity prototypes instead of expensively in code. Design work should be based on use cases wherever possible. For anything with a user interface, ideas progress from rough to precise:
- Sketch. The fastest way to get initial ideas out, share them and get feedback. Quick to draw and easy to understand.
- Wireframe. A skeletal layout of simple shapes that encourages iteration. Its lack of detail is the advantage: stakeholders won’t get stuck on the color of an icon if there is no color.
- Rapid prototype. A “copy-paste” mockup built from screenshots of existing UI combined with wireframe elements. Cheap to make, convincing to stakeholders, and directly usable by the developer who builds it.
- User flow. A diagram of the actions a user can take and their effects, tied to the user’s real workflow.
- User testing. Give the tester enough context, avoid leading questions, and look for weak points and surprises.
You can skip steps, but don’t reverse them. Testing with users isn’t the only way to validate a design: discussions with stakeholders and subject matter experts, role-playing, playtesting a prototype, or walking through each use case with the design all work too.
Writing Good Tasks
Models like INVEST and SMART are useful inspiration, though neither fits implementation tasks perfectly. Eight practices matter most:
- Context, reasoning and end goal. Start wide and state the goal in terms of the user. “Improve performance” is weak. “We see a frame-rate drop when several of the new vehicles are in a mission, and we are committed to supporting this scenario” lets a developer pivot to a better solution if the first one fails.
- Acceptance criteria. Make every task closable: it should be clear what must be true to close it. For example: “average frame rate drops by less than 3% on this mission, and the drop does not grow with more vehicles.”
- Scope. Say what is and isn’t included, including deliberate exclusions and the outcome of discussions. If it is hard to specify, more discussion is needed. Aim for too much detail; people will naturally trim it.
- Small tasks. Big tasks invite scope creep, blur testing, delay feedback and block parallel work. If a task is too hard to describe at a reasonable level of detail, it is probably too big.
- Write the “how.” If nobody knows how yet, create an analysis task first, or pick one approach and scope the task to it. Agreeing on a solution and implementing it are very different amounts of work.
- Keep it up to date. Outdated information has negative value; it misleads. Update the task as you learn.
- Link details. Keep tasks self-contained, but link to detailed documents rather than pasting them. Tasks often outlive the documents and boards around them.
- Specify testing. “If we don’t know how to test it, we probably don’t know what we want.” Thinking about testing also shows where a task can be split. Performance testing in particular needs explicit conditions: which machine, which scenario, how many runs, how it is measured.
Make sure everyone also understands the supporting fields: story points, priority, parent link, sprint, labels and target release.
Key Techniques
Requirements analysis, implementation analysis, prototypes and technical spikes, mind mapping, requirements traceability, user and data flow diagrams, item tracking, backlog refinement and design reviews. See the technique library.