Verified:GitHub

project-manager

Plan sprints and manage project delivery by surfacing risks and dependencies.

3|2|Updated Feb 27, 2026

Search Tags:#planning #retrospective #estimation #backlog #risk-management #velocity #sprint

One-click install

npx skills add https://github.com/grasberg/sofia --skill project-manager-grasberg

Or copy as Structured Prompt for Agent▼

Please help me install this Agent Skill.
Skill: project-manager
Source: https://github.com/grasberg/sofia/tree/main/workspace/skills/project-manager
Command: npx skills add https://github.com/grasberg/sofia --skill project-manager-grasberg

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Delivery is a system, not a heroic effort. The PM's job is to make the path to "shipped" visible, remove obstacles before the team hits them, and say the hard truths about scope and timeline early enough to act on them.

Core Features & Use Cases

Surface bad news early. A missed deadline reported two weeks before the date is a planning problem. Reported the day before, it is a trust problem. Status reports exist to prevent surprises.
Scope is the only lever you control. You cannot add hours to the day or make developers work faster. When timeline pressure increases, negotiate scope using MoSCoW (see below). Every "must-have" added means another item moves to "won't-have."
Velocity is descriptive, not prescriptive. Velocity tells you how fast the team actually moves, not how fast you wish they moved. Use it for forecasting, never as a performance metric. Gaming velocity destroys its predictive value.
Risks are cheap to manage, expensive to react to. A risk register takes 30 minutes per week to maintain. An unmanaged risk that fires costs days or weeks. Every risk needs an owner, a trigger, and a mitigation plan.
Done means deployed and verified, not "code complete." If it is not in production and working, it is not done. Include QA, deployment, and monitoring in every estimate.

Project Recovery Framework

When a project is behind schedule, follow these steps in order:

1. ASSESS (Day 1)
   - How far behind are we? (days/sprints, not vibes)
   - What caused the slip? (scope creep, underestimation, blockers, attrition)
   - What is the remaining work? (re-estimate from scratch, do not trust old numbers)

2. NEGOTIATE SCOPE (Day 2-3)
   Use MoSCoW to categorize remaining work:
   - Must Have: Ship is broken without this. Non-negotiable.
   - Should Have: Important but the product works without it. Defer to fast-follow.
   - Could Have: Nice-to-have. Cut first.
   - Won't Have: Explicitly out of scope for this release. Write it down.

   Example:
   | Feature              | Original | Recovery  | Rationale                         |
   |----------------------|----------|-----------|-----------------------------------|
   | User authentication  | Must     | Must      | Cannot launch without login       |
   | Admin dashboard      | Must     | Should    | Can use direct DB queries for v1  |
   | Email notifications  | Should   | Could     | Manual process acceptable at scale|
   | Dark mode            | Could    | Won't     | Zero impact on core value prop    |

3. REPLAN (Day 3-5)
   - New timeline based on Must Haves only
   - Identify the critical path (longest chain of dependent tasks)
   - Add 20% buffer to the new estimate
   - Get team buy-in on the new plan

4. COMMUNICATE (Day 5)
   - Stakeholder briefing: what changed, why, new timeline, what was cut
   - Frame cuts as "deferred to phase 2," not "removed"
   - Get explicit sign-off on the revised scope

Quick Start

Activate the skill and start a sprint planning session to create a backlog and estimate a sprint.

Frequently Asked Questions about project-manager

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I plan sprints and manage project delivery when timeline pressure increases?▼

Sprint planning manages timeline pressure by negotiating scope using the MoSCoW method, categorizing backlog items into must-have, should-have, could-have, and won't-have to ensure reliable delivery.

Why does velocity show descriptive forecasting value instead of team performance?▼

Velocity is descriptive because it measures actual team movement speed for forecasting, not performance. Using velocity as a performance metric destroys its predictive value and leads to gaming the system.

What is the best way to recover an agile project that is behind schedule?▼

Project recovery requires assessing the delay, negotiating scope via MoSCoW, replanning remaining work with a 20% buffer, and communicating stakeholder briefings with explicit sign-off on revised scope.

When do I need a risk register for backlog and sprint management?▼

A risk register is needed weekly throughout sprint management because risks are cheap to manage but expensive to react to, requiring every risk to have an owner, trigger, and mitigation plan.

How does estimation define done for software delivery in cross-functional initiatives?▼

Estimation defines done as deployed and verified in production, not merely code complete. Every estimate must include QA, deployment, and monitoring to ensure working software delivery.

Can I use retrospective ceremonies to surface dependencies and blockers early?▼

Retrospective ceremonies surface risks and dependencies early in cross-functional initiatives, enforcing structured workflows and clear status reporting to prevent surprises before the deployment date.