Concepts

The methodology behind Skald — why structured data, EARS, MoSCoW, and traceability matter.

Skald is opinionated. It enforces structure that enables human collaboration and AI assistance. This page explains why.

Structured Data Enables AI

This is Skald's core idea. Every feature — rules, examples, questions, priority levels, requirement-to-PBI links — exists because structured data lets AI do useful work.

Capability	What the AI needs	What it can do
Draft requirements	Domain context, existing requirements	Propose structured requirements, detect duplicates
Gap analysis	Rules, examples, questions per requirement	Identify missing edge cases and domains
Planning	Requirements linked to PBIs	Suggest breakdowns, detect unlinked requirements
Workload analysis	Team assignments, estimates	Identify imbalances, suggest rebalancing

The virtuous cycle: better structure → better AI suggestions → better requirements → better AI suggestions.

A well-structured backlog item — with linked requirements, clear rules, and resolved questions — can be handed off to either a human team or an AI agent for implementation. The structure is what makes delegation possible. The PM decides who does the work; the data ensures anyone (human or AI) has enough context to deliver.

Requirements Engineering

Skald combines two methodologies for writing requirements:

EARS (Easy Approach to Requirements Syntax) — structured templates for precise requirements:

Ubiquitous: "The system shall..."
Event-driven: "When [event], the system shall..."
State-driven: "While [state], the system shall..."
Optional: "Where [feature is included], the system shall..."
Unwanted: "If [condition], then the system shall..."

Example Mapping — a discovery technique where each requirement gets:

Rules — business rules that govern the requirement
Examples — concrete scenarios illustrating each rule (optionally in Gherkin)
Questions — unknowns that need resolution before implementation

The result: requirements that developers can implement without guessing, and that AI can analyze for gaps.

MoSCoW Prioritization

Every requirement gets a priority: Must, Should, Could, or Won't.

Priority	Meaning	Badge
Must	Required for this release. Without it, the release fails.	Red
Should	Important but not critical. Include if time allows.	Orange
Could	Nice to have. First to be dropped under pressure.	Yellow
Won't	Explicitly out of scope for this release. Not forgotten — deferred.	Gray

MoSCoW forces real trade-offs. If everything is "Must", nothing is prioritized. Aim for Must items to be under 60% of your backlog.

Traceability

Skald maintains a chain from requirements to delivery:

Requirements (REQ-1, REQ-2, ...) → Backlog Items (PB-1, PB-2, ...) → Teams

This is a many-to-many relationship: one PBI can implement multiple requirements, and one requirement can be addressed by multiple PBIs. This traceability means you can always answer: "which requirements are covered?", "what's left?", and "who's working on what?"

Domain-Driven Thinking

Tag your requirements with a domain — the business area they belong to (e.g., "Payments", "Shipping", "Catalog"). This enables:

Filtering and grouping by business area
Gap analysis across domains (are you missing requirements in Payments?)
Better AI context (the advisor understands which area you're working in)

Pick 5–10 domain labels for your project and keep them consistent.