Delivery Methodologies
Konductro supports three delivery methodologies as a project-level setting. The methodology you choose controls how sprints, boards, and metrics behave — but the underlying data model is the same. You can switch methodologies at any time without losing data.
Choosing a Methodology
Set the methodology in Project Settings > Methodology. Three cards let you select the approach that fits your team.
| Scrum | Kanban | Konductro | |
|---|---|---|---|
| Best for | Teams that want sprint boundaries, velocity tracking, and commitment metrics | Teams that prefer continuous flow with WIP management | Teams that plan in sprints but deliver continuously |
| Sprints | Required — fixed time-box | None | Dev planning only — stories flow after sprint |
| Story intake | Sprint planning | Pull from backlog | Sprint planning |
| Key metrics | Velocity, burndown, commitment ratio | Cycle time, throughput, WIP | Both + resolution gap |
Scrum
Traditional sprint-based delivery. Stories are committed to a time-boxed sprint, developed, tested, and delivered within the sprint boundary.
- Sprint planning — select stories, estimate with story points, assign developers, set dates
- Dev Board — task-level kanban scoped to the active sprint
- Delivery Board — story-level column view (Committed, In Dev, Dev Complete, In QA, Done)
- Sprint Metrics — velocity, commitment vs delivered, cycle time, QA stats, team breakdown
- Sprint completion — captures a snapshot of all metrics for historical tracking
Kanban
Continuous flow without sprint boundaries. Stories are pulled from the backlog when the team has capacity, and flow through development, QA, and release at their own pace.
- Pull from Backlog — developers pull stories into work directly from the delivery board
- Dev Board — task-level kanban showing all in-flight tasks (no sprint scoping)
- Delivery Board — story-level column view showing all in-progress work
- Flow Metrics — WIP, cycle time (avg/P50/P90), lead time, weekly throughput trend
- No sprints — work is continuous, metrics are project-level
Konductro
The signature methodology — "sprint to plan, flow to deliver." Teams use sprints to plan and commit dev work, but stories flow independently through QA and release after the sprint ends.
- Sprint planning — same as scrum: select stories, estimate, assign, start sprint
- Dev Board — task-level kanban scoped to the active sprint
- Delivery Board — pipeline view showing Build, Quality, and Release stages per story, grouped by sprint
- Sprint Metrics — dev-focused: points dev-complete, team breakdown, dev performance (no QA/commitment metrics since those happen post-sprint)
- Resolution gap — tracks how long stories take to reach done after the sprint closes
The pipeline view is the centrepiece. Each story shows its progression through three stages:
| Stage | What it tracks | Colour |
|---|---|---|
| Build | Task completion (merged/done) | Teal |
| Quality | QA rounds (pending, testing, passed) | Purple |
| Release | Environment deployments | Amber |
Stories from multiple sprints appear together on the pipeline — you can see Sprint 3 stories in QA while Sprint 4 stories are still in build. This parallel-streams view is what makes Konductro different from traditional scrum.
Switching Methodologies
You can change a project's methodology at any time in Project Settings. The switch is immediate:
- Existing sprints, stories, and tasks are preserved
- Board views adapt to the new methodology
- Metrics recalculate based on the new lens
No data migration is needed. A project that started as Scrum and switches to Kanban simply stops showing sprint selectors on the boards — the underlying stories and tasks continue flowing.