Create Deliverables is the day-to-day process where the Scrum Team builds, tests, and integrates Sprint Backlog work into a potentially shippable increment that meets the Definition of Done.

Purpose & When to Use

Turn approved Sprint Backlog items into a working product increment. This process runs continuously during the Sprint after Sprint Planning and is owned collectively by the cross-functional Scrum Team.

• Applies to all work types: features, fixes, technical tasks, UX, data, infrastructure, and documentation.
• Guided by the Sprint Goal, user story acceptance criteria, and the team’s Definition of Done.
• Progress is made visible on the Scrumboard and through daily collaboration and integration.

Mini Flow (How It’s Done)

• Pull the next task aligned to the Sprint Goal; ensure acceptance criteria and dependencies are clear.
• Design and implement the solution; pair/mob program and write tests early (unit, API, UI as applicable).
• Perform peer review and static checks; commit to trunk/main and run the CI pipeline.
• Integrate frequently; execute automated tests and exploratory testing; fix defects promptly.
• Update the Scrumboard, Sprint Burndown, and any task remaining hours; raise blockers in the Daily Standup.
• Validate non-functional requirements (security, performance, accessibility, compliance) and data impacts.
• When the item meets the Definition of Done and acceptance criteria, mark it Done and prepare demo notes/data.
• If work cannot finish, surface early to renegotiate scope with the Product Owner or split the item sensibly.

Quality & Acceptance Checklist

• Traceability: task/story links to the Sprint Backlog item and acceptance criteria are verified.
• Definition of Done met: code complete, peer reviewed, tests automated with agreed coverage, CI/CD green, and no open high-severity defects.
• Non-functional requirements validated: performance thresholds, security checks, reliability, accessibility, and compliance as applicable.
• Integration verified: backward compatibility, feature flags as needed, and environment configuration managed.
• Documentation updated: user-facing help, release notes, and technical docs as defined by the DoD.
• Ready for Product Owner review: demo steps prepared; data sets and environments available.
• Logs updated: impediments recorded, risks noted, Scrumboard accurate, and burndown reflects reality.

Common Mistakes & Exam Traps

• Counting partially done work toward velocity or marking Done without meeting the Definition of Done.
• Gold plating: building beyond acceptance criteria or the Sprint Goal without PO agreement.
• Handoffs and mini-waterfalls inside the Sprint instead of cross-functional collaboration.
• Deferring testing and integration to the end of the Sprint, causing last-minute failures.
• Confusing Acceptance Criteria (story-specific) with Definition of Done (team-wide quality bar).
• Ignoring non-functional requirements and compliance until Sprint Review.
• Assuming a change control board must approve mid-Sprint adjustments; in Scrum, the PO manages scope and can renegotiate with the team.
• Failing to update the Scrumboard and impediment log, hiding delays and risks.

PMP/SCRUM Example Question

During Create Deliverables, the team completes the functionality for a story, but the build fails the agreed performance threshold in the Definition of Done. What should the team do next?

1. Mark the story Done and create a new backlog item to address performance later.
2. Pause work and request formal approval from a change control board to add performance work.
3. Improve performance until the story meets the Definition of Done, renegotiating scope with the Product Owner if needed to protect the Sprint Goal.
4. Demo the feature as is and ask the Product Owner to accept it conditionally.

Correct Answer: C. The increment must meet the Definition of Done. If meeting it risks other commitments, the team collaborates with the Product Owner to adjust scope while keeping the Sprint Goal intact.