Key Concepts
Konductro organises software delivery around a small set of core concepts. Understanding these makes the rest of the platform intuitive.
Phases
A phase is a planning container — a set of related features to build. Every story in Konductro belongs to a phase. There are three types:
| Type | Purpose | Planning stages |
|---|---|---|
| Full | Major feature work requiring formal planning | Requirements, Technical Analysis, Architecture, then Story Generation |
| Light | Smaller scope where a quick scoping conversation is enough | Scoping conversation, then Story Generation |
| Ad-hoc | One-off stories created directly from the backlog | None — story created instantly, AI-refined, auto-tagged to an Ad-hoc phase |
Full phases enforce a gate between each stage — nothing moves forward without explicit approval. Light phases skip the formal stages but still produce stories through a structured conversation with Conductor.
Stories
A story is a business-level feature described from the user's perspective. Stories are testable by a non-technical person and represent the unit of delivery that clients and stakeholders care about.
Each story includes:
- Title and user story description
- Acceptance criteria — what must be true for the story to be considered done
- Complexity score — used during sprint planning and estimation
Stories are generated by Conductor during the planning conversation and reviewed by the SDM before entering the backlog.
Tasks
A task is a technical work item under a story, scoped to a specific repository. Tasks carry implementation detail: files to modify, architectural notes, and step-by-step implementation guidance.
Tasks are created during story decomposition — a developer explores the actual codebase with AI assistance and breaks the story into concrete, buildable units.
Methodology
Every project has a delivery methodology that controls how boards, metrics, and planning behave:
- Scrum — traditional sprint-based delivery with velocity and commitment tracking
- Kanban — continuous flow with WIP management, cycle time, and throughput metrics
- Konductro — "sprint to plan, flow to deliver." Sprints scope dev work; QA and release flow independently
The methodology is a lens on the same data — you can switch at any time without losing work. See Delivery Methodologies for details.
Sprints
A sprint is a time-boxed delivery cycle. The SDM creates sprints at the project level, assigns tasks to developers, and sets team capacity. AI-powered estimation suggests hours per task based on complexity and developer profile.
Sprints progress through a lifecycle: Planning (assigning tasks, setting capacity) then Active (development in progress) then Completed (all tasks done, retrospective data available).
How sprints behave depends on the project methodology — required for Scrum, dev-planning-only for Konductro, and not used for Kanban. See Sprint Planning for the full workflow.
Environments
Environments represent deployment targets for a repository — dev, UAT, production. Each environment maps to a git branch and has a display order that defines the promotion path.
One environment per repository is marked as the done target — deploying a story there transitions it to done. The Release Board tracks story progression through environments.
Conductor — the AI Persona
Conductor is the AI persona inside Konductro. It assists at every planning stage — requirements, technical analysis, architecture, story generation, and estimation.
Conductor remembers what was decided at each step. When the Architect opens the architecture stage, Conductor already has the approved requirements and technical analysis as context. When stories are generated, Conductor draws on all three approved artefacts. No one re-explains decisions that were already made.
Artefacts
An artefact is a document produced during phase planning. There are three types, one per stage:
- Requirements — what needs to be built, written during the requirements stage
- Technical Analysis — how the codebase supports it, produced by a developer exploring real code
- Phase Architecture — data models, API contracts, and deployment strategy, grounded in the first two artefacts
Each artefact is reviewed and approved before the next stage begins. Together they form the context thread that flows through the entire delivery lifecycle.
The Context Thread
The defining idea behind Konductro: decisions made early flow forward automatically. Requirements inform technical analysis. Technical analysis informs architecture. Architecture informs stories. Stories inform tasks. Tasks carry their full context into the developer's IDE.
No re-typing. No handoff meetings. No "what did we decide about that?"