The SDLC work model
How Disco Parrot organizes work. Portfolios, projects, initiatives, plans, bugs, sprints, and goals, and how they connect.
Disco Parrot models your software development lifecycle as a small set of linked records. They are not freeform documents. Each one has a defined shape, a status it moves through, and relationships to the others. That structure is what lets an agent read your work, fill it in, and act on it, and what lets you sort, filter, and roll up across everything in one place.
This page is the map. Each record has its own guide under Plan & track work with the full set of fields, statuses, and actions.
The shape of work
Work nests from broad to specific, with two layers that cut across the rest.
- A portfolio groups related projects. A project can belong to more than one portfolio.
- A project is the unit of delivery. It is anchored to a repository and is where initiatives live.
- An initiative is a unit of intent: a feature, a change, an outcome. It breaks down into plans, and it can depend on other initiatives.
- A plan is a single body of work with steps and acceptance criteria. A plan can produce bugs and link to test cases.
- A sprint is a time box owned by a team. It pulls plans and bugs from across the work into a scheduled set. Sprints sit alongside the hierarchy rather than inside it.
- Goals and their key results track outcomes. They are owned at the workspace or project level and link up to initiatives and portfolios.
The building blocks
| Record | What it is |
|---|---|
| Portfolio | A grouping of projects, with its own privacy and ownership. The same project can roll up into several portfolios. |
| Project | A repository-anchored unit of delivery that holds initiatives. |
| Initiative | A unit of intent that decomposes into plans, carries open questions, and can depend on other initiatives. |
| Plan | A single body of work, with steps and acceptance criteria, in one of seven types (below). |
| Bug | A defect, with severity, priority, relationships to other items, and a resolution. |
| Sprint | A team-owned time box that schedules plans and bugs together. |
| Goal and key result | An outcome and the measures that track it. |
| Test case | Steps and expected results, linked to the verification plans that check them. |
| Document | A file or reference, attachable to the records above. Repository documentation is the related concept for the pages that describe each repo. |
Statuses at a glance
Each record type moves through its own set of statuses. These are the defaults; a workspace can tailor them through Workflows.
| Record | Default statuses |
|---|---|
| Initiative | planning, approved, in progress, blocked, done, cancelled |
| Plan | draft, in progress, complete, blocked, cancelled |
| Bug | triage, backlog, todo, in progress, in review, fixed, verified, closed, canceled |
| Sprint | planned, active, completed |
| Test case | draft, active, passing, failing, obsolete |
| Goal | on track, at risk, off track, achieved, cancelled |
| Project | active, paused, completed, archived |
| Portfolio | active, archived |
A test case is a useful special case: its passing and failing statuses are not set by editing the record. They are recorded when a verification plan reports a result, so the status reflects a real run rather than someone's note.
How the pieces connect
The relationships are specific, and a few of them surprise people.
- A plan and a bug always belong to an initiative. A plan also belongs to a project through that initiative. A bug can optionally point at the plan it relates to, but its required parent is the initiative, so a bug filed on its own still has a home.
- Portfolios and projects are many-to-many. The same project can roll up into several portfolios at once.
- A plan or a bug belongs to at most one sprint at a time. Adding it to a sprint sets a field on the record itself, which is why a sprint board can show work drawn from more than one project, and why moving an item between sprints is a single change.
- Sprints are owned by a team, not by a project or initiative. A team schedules the work it owns, wherever that work lives.
- Key results link to initiatives or portfolios. A key result linked to an initiative contributes to its goal's progress automatically, computed from the linked work. A key result linked to a portfolio shows up on the portfolio's Overview tab as a Connected goal but does not feed the automatic progress number; the portfolio is a target the leader cares about, not a driver of the metric.
The landing dashboard at /planning is labeled Portfolio. The Portfolios entry in the navigation is the list of portfolio records. They are different surfaces: the dashboard is a roll-up view of everything, and a portfolio is a record you create and manage.
Plans come in types
A plan is not one fixed shape. Each plan has a type that tells the platform and your team what kind of work it is. The type changes which fields and actions appear, while every type shares one status model.
| Plan type | Use it for |
|---|---|
| Implementation | Building or changing code. Carries branch, pull request, and sandbox fields. |
| Design | Working out an approach or interface before code. |
| Spec | Writing a specification. |
| Review | A focused review pass. |
| Research | Investigation and findings. |
| Chore | Maintenance and housekeeping. |
| Verification | Confirming behavior. Links to the test cases it checks. |
Only implementation plans surface the branch, pull request, and sandbox fields, so a research or design plan stays uncluttered.
The model is open and queryable
Because every record has a defined shape, the whole work model behaves like a queryable system rather than a pile of pages. The Built for query page covers this in full, including the runtime fetch interface the agent uses to gather context during a Flow; the short version is here.
- Any list can be sorted, filtered, and saved as a shareable view. The filters live in the page URL, so a filtered list is a link you can send to a teammate.
- Parent records roll up their children. An initiative shows the count of its plans, how many are complete, a progress percentage, and the count of its open bugs. Progress is the share of plans that are complete, leaving cancelled plans out of the math, so a cancelled plan never drags a number down.
- Records link to each other, so you can move from an initiative to its plans, from a plan to its bugs and test cases, and from a bug to its plan when it has one.
See the grid, the board, the roadmap, and Quick View for the surfaces these records are presented through.
How agents fill it in
When you continue an initiative in chat, the platform writes that initiative, its plans, and its bugs into the agent's sandbox as files. The agent edits those files as part of its work. After each turn, the platform reads the changed files back and updates the records. A Flow authors these records the same way: a plan step creates a real plan, and an initiative step creates a real initiative.
Edits an agent makes are saved with an ai source tag, separate from the user edits people make and the system edits the platform makes on its own. That tag flows into version history and the audit log, so you can always tell the agent's work apart, and restore any of it.
For the field-by-field reference of every record, the seven plan types, and the bug value sets, see work items, fields, and types.