6.2Agile project management

The belief that "agile is always superior" is a misconception. What is asked of a PM is the judgment to determine which lifecycle minimizes risk for the project at hand—by assessing how firm or how likely to change the requirements are, and choosing between a predictive approach that fixes the plan up front and an adaptive approach that continually revisits the plan in short iterations.

6.2.1Scrum and sprint operation

• Scrum is a leading agile framework that selects items to build from a prioritized product backlog for each fixed-length period (a sprint, typically 1-4 weeks), iteratively building working deliverables. At the end of each sprint the deliverable is reviewed and feedback is folded into the next sprint's planning, allowing changes or misunderstandings in requirements to be corrected early.
• Because of sprint iteration, even exploratory development where requirements are not yet firm can show something actually working early and correct direction along the way. On the other hand, for a project where contractual or regulatory constraints require the full scope of deliverables to be fixed up front, Scrum, whose scope can shift with each iteration, does not fit as-is.

6.2.2Burndown chart and velocity

• Burndown chart: a chart with remaining work on the vertical axis and time (days) on the horizontal axis, visualizing how remaining work decreases over the sprint. If the actual line sits above the ideal line, that signals schedule delay; if it sits below, that signals the team is ahead of schedule. The PM or Scrum Master uses this gap as material to detect deviation early and decide on a response.
• Velocity: the actual amount of work (story points, etc.) a team completes per sprint. It is calculated from the last several sprints' results and used for future sprint planning and release planning (remaining work / velocity = estimated remaining sprints). Velocity is not a comparison metric between individuals or across teams—it is used strictly as an internal metric to improve that team's own planning accuracy.

Suppose a PM is juggling two projects at once. Project A is a government agency's core-system replacement, where the procurement specification details the scope, functions, and acceptance criteria of deliverables at the ordering stage, and contract changes require a formal procedure and take time. Project B is an app for the company's new business line, where the direction of functionality must be settled while watching target customers' reactions, and management has asked to "see something working early and decide from there." For project A, because requirements are already fixed contractually and the cost of changing them later is high, the PM chooses a predictive (waterfall-style) lifecycle that fixes the plan before executing—an adaptive approach, whose scope can shift with each iteration, would only increase the effort and risk of repeatedly re-aligning with the contractual specification. For project B, because requirements are inherently uncertain and getting early feedback from customers and management by showing something working is key to success, the PM chooses an adaptive lifecycle via Scrum, iteratively building out the product backlog in two-week sprints. In project B's third sprint, the PM notices the burndown chart's actual line sits clearly above the ideal line and diagnoses this as a sign of schedule delay. Investigating the cause reveals that the team's velocity over the last three sprints has been lower than assumed at initial planning. The PM takes the corrective action of dividing the remaining work by this measured velocity and realistically revising the release plan (the number of remaining sprints) based on actual results—using velocity as a metric to improve the team's own planning accuracy, not as material for comparing against other teams or evaluating individuals, is the appropriate judgment. In this way, choosing a lifecycle based on how firm a project's requirements are, and, once adaptive is chosen, continuously monitoring burndown/velocity to keep the plan aligned with reality, is what the PM's practice looks like.

6.2.3Section summary

• Scrum iteratively realizes the product backlog each sprint, folding review feedback into the next sprint
• On a burndown chart, actual above ideal = delay, below = ahead of schedule. Velocity is an internal metric for improving a team's own planning accuracy
• Choose between predictive (fixed requirements, high change cost) and adaptive (uncertain requirements, values early feedback) based on requirements firmness and change cost