Each technique answers three questions: why it matters, what it is, and how to do it. The origin shows which discipline it comes from. Pick the ones that fit your project; no project needs all of them.
Understanding the Need
Business Need
Business analysisThe mission, in this methodology.
Why before thinking about how to do a project, understand what outcome it must achieve and why anyone would pay for it.
What the real-world outcome the customer needs, their motivation for paying, and your organization’s strategic reasons to take the work on, such as entering a new market.
How interview the sponsor and major stakeholders. Write it down, but brief it verbally too; Q&A makes it stick.
Training Goals (User Goals)
Business analysisMission objectives, in this methodology.
Why meet user and mission needs, not just requirements. A feature is not an objective; ask why the customer wants each feature until you find the real objective.
What high-level objectives tied to the mission, broken into discrete real-world tasks users need to train or accomplish. Never handed to you; you must ask.
How usually elicited by interviewing subject matter experts, sometimes by research. Record it as use cases, storyboards or plain text.
Stakeholder Interview / Review
UX design, business analysisWhy capture the knowledge of someone who understands the user need or the project context.
How do your homework and prepare questions. Take notes as if someone else will read them. Then actually use the answers to update your work, and link the notes from the project overview.
Product Research
GeneralWhy mature products have huge numbers of features; reuse what exists instead of building from scratch.
How use the product hands-on, read the documentation, ask people who know it better, and only as a last resort rely on videos and marketing material.
Competitive Research
GeneralWhy learn from how others have solved the same problem.
How study competing and adjacent products, including ones outside your industry.
Defining Scope
Use Cases
UX design, business analysisWhy a more user-centered way to understand what the software should do than requirements alone.
What step-by-step descriptions of what the user will do and see, written before the software exists.
How write one high-level use case for the overall scenario, then lower-level ones per feature. Simple, and one of the most powerful techniques there is. See Use Case Documents for a template and example.
Storyboard
UX designWhy a picture is worth a thousand words. Especially useful for mission objectives and unusual physical setups.
How imagine a documentary of someone using your software or running the training. Your storyboard is a few key frames of that film.
Features Breakdown
Game designWhy requirements rarely map neatly onto features.
What a bullet list, or mind map, of the features to build or change to meet the requirements.
How once you understand the requirements, name the features. Anyone can then discuss, estimate and prioritize the list without deep technical knowledge.
Requirements Specification
Business analysisWhy contracts should rest on written requirements, not personal relationships or conversations.
How if the customer has no written requirements, elicit and write them. If they do, check they are well written: clear, testable and bounded. Limit them where they aren’t.
Non-Functional Requirements
Business analysisWhy performance, scale, security and hardware constraints shape a design as much as features do.
How ask about them explicitly; customers rarely volunteer them.
Design Document
GeneralWhy a smooth handover from estimate to pre-production.
What a standard format packaging all the design work done during the estimate.
How keep a template and fill it in for every project.
Designing the Solution
System Architecture Diagram
Business analysisWhy essential when several systems are involved or the setup is non-standard.
What a box diagram of how the hardware and software connect.
How after talking to commercial and technical stakeholders, draw the target setup simply.
Requirements Analysis
Business analysisWhy requirements are rarely complete or self-explanatory.
What organizing, modeling and expanding on a set of requirements.
How usually an extension of the design document, focused on a narrower set of requirements.
Implementation Analysis
Mission-Centered DesignWhy get feedback on the planned approach before building it.
What one short document combining the feature design and the technical approach; in effect, a code review before coding.
How look into the code, write the approach down, and use it to find dependencies, split your work into estimable chunks, and identify work for others.
Prototype / Technical Spike
GeneralWhy some questions are only answered by building something.
How timebox a throwaway prototype aimed at one question, then decide.
Mind Mapping
UX design, business analysisWhy break something too large and complex to grasp into understandable pieces.
How map concepts visually and how they relate. Also useful for showing how a project’s documents connect.
User / Data Flow Diagram
UX design, business analysisWhy make the steps, decisions and effects of a feature visible.
How diagram each user action and its result, tied to the user’s real workflow.
Requirements Traceability
Business analysis, project managementWhy prove every requirement was met.
How link each requirement to the use cases, features and tasks that satisfy it, and to the tests that validate it.
Item Tracking (Questions, Decisions, Issues)
Business analysisWhy open questions and decisions get lost in chat and meetings.
How keep one list of open items, owners and outcomes, linked from the project overview.
Validating and Tracking
Playtesting
Game designWhy task-level testing misses problems that fall between tasks.
How play through the use cases. Early on, use placeholder features before the final ones exist.
Project Progress Tracking
Project managementWhy answer “when will it be done?” honestly.
How combine several completion measures with historical velocity. See Production.
Collaboration
Estimation Meeting
Mission-Centered DesignEstimation needs discussion, Q&A and brainstorming; it can’t be done alone. Everyone involved assigns an estimate per requirement, using relative sizing and recording assumptions.
Backlog Refinement
ScrumTeams shouldn’t work on vague tasks like “make feature X.” Turn verbal discussion into written, well-defined backlog items.
Design Review Meeting
UX design, business analysisWalk stakeholders and developers through a design before it is built, and record the decisions.
Team Standard Operating Procedures
GeneralPut good habits on autopilot: task workflows, required fields, definitions of ready and done, meeting formats, and roles. Improve them in retrospectives.
External Coordination
Mission-Centered DesignWork across team lines needs extra care. Assign one point of contact, keep the other team’s lead in the loop, and remember their lead sets their priorities, not you.
Bug Triage
Quality assuranceA standard process for prioritizing bugs so they don’t overwhelm the team. See Production.