Ordering Strategy Variations

Input: $ARGUMENTS

Overview

Alternative ordering strategies for procedure steps. The base order_procedure uses a default prioritization. These variations offer different sequencing philosophies, each optimal for different contexts.

Steps

Step 1: Identify the Steps to Order

What are the steps/tasks that need sequencing?
What are the hard dependencies? (A must come before B)
What resources are available?
What is the primary concern? (This determines which ordering to use)

Step 2: Select Ordering Strategy

Primary Concern	Strategy	Philosophy
Minimize risk	Risk-First	Do the scariest things first
Maximize learning	Learning-First	Do the most uncertain things first
Build momentum	Quick-Win-First	Do the easiest valuable things first
Meet deadline	Critical-Path	Do things on the longest dependency chain first
Reduce waste	Value-Stream	Do things in order of value delivery
Handle complexity	Outside-In	Start at interfaces, work toward core
Handle complexity	Inside-Out	Start at core, work toward interfaces
Maintain motivation	Alternating	Alternate hard and easy tasks
Satisfy stakeholders	Stakeholder-Priority	Do what the most important stakeholder needs first
Manage resources	Bottleneck-First	Start with whatever uses the scarcest resource
Maximize parallelism	Independence-First	Do independent tasks first to enable parallel work
Explore options	Breadth-First	Survey all options before going deep on any
Exploit known good	Depth-First	Go deep on most promising path first

Step 3: Apply Selected Strategy

Risk-First Ordering:

List all risks associated with each step
Score: likelihood × impact for each
Order steps so highest-risk steps come earliest
Rationale: Discover showstoppers before investing in everything else

Learning-First Ordering:

For each step, estimate: how much do we learn by doing it?
Order by information value (most informative first)
Allow re-planning after high-learning steps
Rationale: Reduce uncertainty before committing

Quick-Win-First Ordering:

For each step, estimate: effort required and value delivered
Calculate value/effort ratio
Order by ratio (highest first)
Rationale: Build momentum and demonstrate progress early

Critical-Path Ordering:

Map all dependencies
Find the longest chain (critical path)
Prioritize tasks on the critical path
Parallelize non-critical-path tasks
Rationale: The critical path determines the timeline

Value-Stream Ordering:

Identify the flow from start to delivery
Order steps to deliver a complete (if minimal) value stream first
Then add capability in subsequent passes
Rationale: Deliver working value as early as possible

Outside-In Ordering:

Define the interfaces/boundaries
Specify interfaces first
Then implement what’s behind each interface
Rationale: Interfaces constrain everything; define them first

Inside-Out Ordering:

Identify the core/kernel
Build the core first
Then add layers outward
Rationale: The core determines everything; get it right first

Step 4: Validate the Ordering

After applying the strategy:

Do all hard dependencies hold? (Nothing depends on something that comes later)
Does the ordering match the primary concern?
Are there any steps that could be parallelized?
Is the first step achievable? (Don’t start with something blocked)
Is there a natural review point after the first few steps?

Step 5: Compare Alternatives

If unsure which strategy fits:

Step	Risk-First	Learning-First	Quick-Win	Critical-Path
[step A]	2nd	1st	3rd	1st
[step B]	1st	3rd	1st	2nd
[step C]	3rd	2nd	2nd	3rd

If multiple strategies agree on what comes first → high confidence. If they disagree → the primary concern should be the tiebreaker.

Step 6: Report

ORDERING STRATEGY:
Steps to order: [N]
Primary concern: [risk/learning/momentum/deadline/value/complexity/motivation]
Strategy selected: [which ordering]

Ordered sequence:
1. [step] — rationale: [why first]
2. [step] — rationale: [why second]
3. [step] — rationale: [why third]
...

Dependencies honored: [yes/no]
Parallelizable steps: [which can run concurrently]
First review point: [after which step]

Alternative orderings considered:
- [strategy]: Would put [step] first instead — better if [condition]

When to Use

Default ordering doesn’t fit the situation
Context strongly favors one concern (risk, time, learning, etc.)
Need to compare different ordering approaches
Building step documents and need to justify sequence
→ INVOKE: /ovi (ordering variations integration) for selecting ordering strategy
→ INVOKE: /to (topological ordering) for dependency-based ordering

Verification

Primary concern identified
Strategy matched to concern
All hard dependencies respected
Ordering rationale stated for each step
Alternative strategies considered
Parallelizable steps identified

ov