Iterations, flow and progress evidence

Concept and mechanism

Iteration planning starts with the outcome sought or uncertainty that matters to reduce. A long task list does not by itself explain why the work is worthwhile. Define a slice that enables observing useful behavior, conditions for recognizing completion and who can provide relevant feedback.

Reuse scope and dependency information even when it comes from a WBS prepared for predictive delivery. A technical-layer structure may need reorganizing: isolated interface, rules and data do not necessarily form a usable delivery. One simple end-to-end flow can test a hypothesis with less commitment.

Splitting scope does not mean reducing mandatory quality conditions. A simulation can support interaction learning but does not establish real integration or production authorization. Keep that boundary explicit when presenting the demonstration and selecting subsequent work.

Guided application

In a fictional service, the objective is to let a customer request one simple refund, see validation and receive confirmation. A management report is desirable but unnecessary for that outcome. The team identifies an external certificate dependency with a one-week lead time.

Preparing it only on the final day would compromise the forecast. During work, a small change needed for confirmation emerges. If removing the optional report keeps the Sprint Goal viable, the Product Owner and Developers can clarify that scope adjustment and Developers update the plan.

They neither call the slice complete without confirmation nor remove validation to retain every initially selected item. Review considers what is actually Done and why it differs from the forecast. The information supports better subsequent selection and preparation without deleting history.

Artifacts and decisions during the iteration

In Scrum, the Product Goal is the Product Backlog commitment, the Sprint Goal is the Sprint Backlog commitment and the Definition of Done is the Increment commitment. Developers select work considering past performance, availability and completion conditions.

The Sprint Backlog evolves with learning without turning each new request into an automatic obligation. Collaborate with the Product Owner when scope needs clarification or renegotiation and retain the goal. An item failing Done does not become complete because the Sprint ends.

It stays visible for future consideration in the Product Backlog. Goals and criteria support discussing why six completed items from an eight-item forecast may still represent a useful outcome, or why eight superficially finished items may fail the intended outcome.

Do not convert points into hours or compare teams without an adequate basis.

Interpret charts and populations

A remaining-work burndown may rise when necessary work is discovered; this does not prove the team stopped working. A burnup with total-scope and completed-work lines helps separate delivery from scope growth. Twenty units completed within scope of 80 represent 25%; if scope becomes 100 without further completion, they represent 20%.

The lower percentage does not delete completed work. Annotate the change instead of rewriting history. On a cumulative flow diagram, a widening validation band suggests accumulation: investigate capacity, blockers and policies without presuming one cause.

Measure throughput as completions per period. Accompany finished-item cycle-time distributions with open work age; finishing fast items while old ones remain blocked can improve the median without restoring service for everyone.

Priority and success with explicit conditions

Order work considering impact, risk, urgency, effort, dependencies and execution conditions. Higher expected value does not require starting a blocked item before obtaining necessary authorization; it may justify preparing the dependency and selecting another useful outcome meanwhile.

For a pilot, define population, observation window and joint criteria in advance. If the target is reducing support contacts to at most 20 per 100 users while keeping errors below 3%, observing 18 contacts and 6% errors does not meet the complete criterion.

Record both improvement and failed condition, investigate rework and decide whether a correction merits another experiment. Do not turn errors into additional deliveries to inflate volume. Outcome criteria guide decisions to continue, adapt or stop, and the record retains conditions making comparison valid.

Common pitfalls

Confusing effort with completion; replacing the goal with task count; hiding discovered work to preserve a chart; comparing different point scales; presenting a median as a maximum duration; excluding old open items; changing success criteria after learning the outcome.