How to Use Agile Artifacts for Scope Management - dummies

How to Use Agile Artifacts for Scope Management

By Mark C. Layton

From the vision statement through the sprint plan, all the artifacts in agile project management support you in your scope management efforts. Decompose requirements progressively as features rise to the top of the priority list. The table shows how each artifact, including the product backlog, contributes to ongoing scope refinement.

Agile Artifacts and Scope Management Roles
Artifact Role in Establishing Scope Role in Scope Change
Vision Statement: A definition of the product’s
end goal.
Use the vision statement as a benchmark to judge whether
features belong in scope for the current project.
When someone introduces new requirements, those requirements
must support the project vision statement.
Product Roadmap: A holistic view of product
features that create the product vision.
Product scope is part of the product roadmap. Requirements at a
feature level are good for business conversations about what it
means to realize the product vision.
Update the product roadmap as new requirements arise. The
product roadmap provides visual communication of the new
feature’s inclusion in the project.
Release Plan: A digestible mid-term target
focused around a minimum set of marketable features. Chapter 8 has
more about the release plan.
The release plan shows the scope of the current release. You
may want to plan your releases by themes — logical groups of
requirements.
Add new features that belong in the current release to the
release plan. If the new user story doesn’t belong in the
current release, leave it on the product backlog for a future
release.
Product Backlog: A complete list of all known
scope for the product.
If a requirement is in scope, it is part of the product
backlog.
The product backlog contains all scope changes. New,
high-priority features push lower-priority features down on the
product backlog.
Sprint Backlog: The user stories and tasks within
the scope of the current sprint.
The sprint backlog contains the user stories that are in scope
for the current sprint.
The sprint backlog establishes what is allowed in the sprint.
Once the development team commits to the sprint goal in the sprint
planning meeting, only the development team can modify the sprint
backlog.