Wip review

WIP Review

Review work-in-progress for "$ARGUMENTS". Count items by status, check WIP limits, compare progress to burndown, identify bottlenecks and idle capacity, and recommend adjustments.

Prerequisites

Check that .project/$ARGUMENTS/00-initiate.md exists. If it does not, tell the user to run an Initiate skill first (e.g., project-charter) and stop.

If the user passes --skip-checks, skip the prerequisite check and log the skip to .project/$ARGUMENTS/skip-log.md with a timestamp and reason.

Process

1. Read existing context:

   • Read .project/$ARGUMENTS/00-initiate.md for team roster and project context
   • Read .project/$ARGUMENTS/02-sprint.md if it exists (for sprint state, standups, and previous WIP reviews)
   • Read .project/$ARGUMENTS/01-plan.md if it exists (for sprint backlog, assignments, and capacity)

2. Count items by status:

   • Categorize all sprint backlog items into columns: To Do, In Progress, In Review, Done
   • Count items and story points in each column
   • Calculate percentage of total work in each status
   • Show the flow: how many items moved between columns since the last review

3. Check WIP limits:

   • Recommended WIP limit: no more than 2 items per person in progress at any time
   • For each team member, count their in-progress items
   • Flag anyone exceeding the WIP limit (context switching reduces productivity)
   • Flag anyone with zero in-progress items (possible idle capacity or blocker)
   • If the team as a whole has too much WIP, recommend finishing before starting

4. Compare progress to burndown ideal line:

   • Calculate sprint progress: % of sprint elapsed (days elapsed / total sprint days)
   • Calculate work progress: % of sprint goal completed (points done / total points committed)
   • Compare the two: work progress should be close to or ahead of sprint progress
   • Classify status:
     • Ahead: work progress > sprint progress + 10%
     • On Track: work progress within 10% of sprint progress
     • Behind: work progress < sprint progress - 10%
     • At Risk: work progress < sprint progress - 25%
   • If behind or at risk, calculate how much work needs to complete per remaining day to recover

5. Identify bottlenecks:

   • Where is work piling up? (e.g., many items in "In Review" means review capacity is the bottleneck)
   • Are there stories that have been in progress for more than 2 days without moving? (stuck work)
   • Is one person assigned to too many stories? (overloaded team member)
   • Is one skill area blocking others? (e.g., all backend work done but frontend is bottlenecked)
   • For each bottleneck, explain the impact and suggest a remedy

6. Identify idle capacity:

   • Who has bandwidth to take on more work?
   • Are there team members who completed their tasks and have nothing queued?
   • Can idle capacity be redirected to help with bottlenecks?
   • Is idle capacity a sign that work was not broken down enough (large stories blocking parallelism)?

7. Calculate sprint goal completion percentage:

   • % of sprint goal completed = completed story points / committed story points
   • % of sprint elapsed = days elapsed / total sprint days
   • Sprint health ratio = (% goal completed) / (% sprint elapsed)
   • Health ratio > 1.0 = ahead, 0.9-1.0 = on track, 0.7-0.9 = behind, < 0.7 = at risk
   • Project estimated completion: at current velocity, when will committed work be done?

8. Recommend adjustments:

   • If ahead: consider pulling stretch goals into the sprint
   • If on track: maintain current pace, no changes needed
   • If behind: recommend specific actions:
     • Re-prioritize: focus on sprint-goal stories, defer non-essential work
     • Swarm: redirect idle capacity or multiple people to the most critical stories
     • Cut scope: remove stretch goals or negotiate committed scope with the product owner
     • Resolve blockers: escalate any blockers that are slowing progress
   • If at risk: recommend an immediate conversation with the product owner about scope

9. Write the artifact — append to .project/$ARGUMENTS/02-sprint.md under a ## WIP Review section:

   • Status Board — items and points by column (To Do, In Progress, In Review, Done)
   • WIP Limit Check — per-person WIP count with flags for violations
   • Burndown Status — sprint progress vs. work progress with classification
   • Bottlenecks — identified bottlenecks with impact and remedies
   • Idle Capacity — team members with bandwidth and suggested reallocation
   • Sprint Health — completion percentage, health ratio, and projected completion
   • Recommended Adjustments — specific actions based on current status

Output

WIP review appended to .project/$ARGUMENTS/02-sprint.md. Present a summary highlighting:

• Sprint burndown status (ahead/on-track/behind/at-risk)
• Sprint health ratio
• Number of WIP limit violations
• Top bottleneck and recommended action
• Key adjustment recommendation