S
STRIDE

Workflow

How work flows through Stride from planning to delivery. Understand the status model, lifecycle management, and how progress rolls up through the hierarchy.

The Status Model

Stride uses a simple, two-level status system. Status Categories provide high-level groupings that work across all types of work, while Status Codes offer granular tracking that teams can customise to match their workflow.

Not Started
Backlog, Ready
In Progress
Active work
In Review
Testing, QA
Completed
Done, Shipped
Blocked — Work can become blocked at any stage

Status Categories

Every work item belongs to exactly one status category at any time:

Not Started

Work that hasn't begun yet. Includes backlog items and work that's ready to be picked up.

In Progress

Work that's actively being done. Someone is working on this right now.

Completed

Work that's finished. For tasks, this means done. For outcomes, it means all tasks complete and value delivered.

Blocked

Work that can't proceed due to a dependency, question, or impediment. Requires explicit resolution.

Archived

Work that's been cancelled or deferred indefinitely. Hidden from active views but preserved for reference.

Why Categories Matter

Status categories enable automatic progress tracking. When you filter by “In Progress”, you see all active work regardless of whether a team calls it “In Development”, “Coding”, or “Building”. Categories provide consistency while allowing team-specific terminology.

Task Lifecycle

Tasks are the atomic unit of work in Stride. They follow a straightforward lifecycle from creation to completion.

Typical Task Flow

1

Created → Backlog

Task is created and added to the user action's task list. Not yet assigned or scheduled.

2

Ready

Task has all the information needed to start. Requirements are clear, dependencies resolved.

3

In Progress

Someone is actively working on the task. Typically assigned to a specific team member.

4

In Review

Work is done, awaiting review, testing, or approval before marking complete.

5

Completed

Task is done. Acceptance criteria met, code merged, or deliverable approved.

Task Best Practices

  • • Keep tasks small enough to complete in a day or two
  • • Include clear acceptance criteria so “done” is unambiguous
  • • Assign a single owner—shared ownership means no ownership
  • • Don't create tasks without a user action—every task contributes to user value

Outcome Lifecycle

Outcomes represent user value. Their lifecycle is driven by the completion of underlying user actions, but they also have their own status progression.

Outcome Progression

1

Defined

Outcome is described but no user actions created yet. The “what” is clear, the “how” is not.

2

Planned

User actions have been created. The functional design is complete.

3

In Progress

At least one user action is being worked on. Progress is visible through task completion.

4

Completed

All user actions done and the outcome is delivered. Users can now do something they couldn't before.

Automatic Progress Calculation

Outcome progress is automatically calculated from user action completion. If an outcome has 4 user actions and 3 are complete, the outcome shows 75% progress. This provides real-time visibility without manual status updates.

Release Lifecycle

Releases are strategic milestones. Their lifecycle reflects the journey from planning through delivery.

Release States

Planning

Outcomes are being pulled in. Scope is still being shaped and refined.

Active

The team is actively working toward this release. It's the current focus.

Shipped

The release has been delivered to users. Outcomes are available.

Archived

Historical release. Kept for reference but no longer active.

Handling Blockers

Blocked work is a reality of software development. Stride makes blockers visible and trackable.

When to Mark Work as Blocked

  • Waiting on external dependency — API access, third-party service, vendor response
  • Blocked by another task — Work can't proceed until prerequisite is complete
  • Requires clarification — Requirements unclear, need product decision
  • Technical impediment — Environment issue, missing access, infrastructure problem

Resolving Blockers

1

Document the blocker

Add a comment explaining what's blocking and what's needed to unblock.

2

Assign ownership

Someone should own resolving the blocker, even if different from the task owner.

3

Unblock and resume

Once resolved, move work back to its previous status and continue.

Continue Learning

Understand how teams work together with clear roles and ownership.