Work Structure
Stride uses four building blocks to structure delivery: Releases, Outcomes, User Actions, and Tasks. This hierarchy connects strategic planning to daily execution.
On This Page
The Four-Level Hierarchy
Every piece of work in Stride fits into one of four levels. This structure ensures that business needs flow through functional design into technical implementation—with clear accountability at every stage.
Release
Delivery target
Outcome
What the user can achieve
User Action
What the user does in the system
Task
Task
Task
Task
The Flow of Work
Work flows downward through design and upward through completion. Business needs define Outcomes. Functional Designers create User Actions. Developers build Tasks. As Tasks complete, User Actions complete; as User Actions complete, Outcomes complete; as Outcomes complete, Releases ship.
Releases
Releases are delivery targets—high-level milestones representing meaningful product versions or feature sets. They provide the strategic view of what's being delivered and when.
A Release contains the Outcomes to be delivered. It can be time-boxed (“Q1 2025”) or scope-defined (“Mobile v2.0”). Progress is measured by Outcome completion.
Good Release Names
- • Q1 2025 Launch
- • Mobile App v2.0
- • Enterprise Features
- • Public Beta
Release Ownership
The Release Owner is accountable for the release shipping successfully. They prioritise Outcomes, manage timeline, and communicate to stakeholders.
Outcomes
Outcomes are what the user can achieve using the system. They represent tangible value delivered—answering: “What will users be able to do that they couldn't before?”
Outcomes are driven by user and business needs. They define the “what” without specifying the “how”. An Outcome is complete when all its User Actions are complete.
Writing Good Outcomes
Focus on user capability, not implementation. Start with “Users can...” or describe the result from the user's perspective.
- • Users can book appointments directly
- • Dashboard loads in under 2 seconds
- • Mobile checkout is seamless
- • Implement booking API
- • Add caching layer
- • Refactor checkout component
User Actions
User Actions are the actual things the user does in the system to achieve an Outcome. This is where functional design happens—translating business needs into concrete user interactions.
Functional Designers take Outcomes and create User Actions. Each User Action describes a specific interaction: a form submission, a navigation flow, a data operation from the user's perspective.
The Bridge Between Business and Technical
User Actions are critical. They bridge the gap between what the business wants (Outcomes) and what developers build (Tasks). A well-defined User Action makes Task creation straightforward because it clearly specifies what the user does, sees, and experiences.
Example: Breaking Down an Outcome
Tasks
Tasks are the implementation work that developers do to build User Actions into the system. They're actionable, technical, and assigned to individual team members.
Developers take User Actions (not Outcomes) and break them into Tasks. Each Task describes what needs to be built, coded, tested, or configured. When all Tasks under a User Action complete, the User Action is complete.
Example: Tasks for a User Action
Task Best Practices
- • Keep tasks completable in a day or two
- • Include clear acceptance criteria
- • Assign a single owner—shared ownership means no ownership
- • Every task belongs to a User Action (no orphan work)
Continue Learning
See how work flows through these levels from planning to delivery.