SCRUM Phases and Underlying Processes
An Agile Life Cycle Model
Edited by Keith A. Thomas, PMP, MBA
Project Phase: SCOPING PHASE
Process Description: Idea Creation
In SCRUM, the Product Owner, or customer, begins the process by defining a new or enhanced system.
The Product Owner develops a high-level description in the form of a Product Overview Statement (POS).
If necessary, a Condition of Satisfaction (COS) statement may complement the Product Overview
Statement (POS) to ensure a well-defined project statement is produced and agreed upon by key
stakeholders.
Deliverable: A Condition of Satisfaction statement
Deliverable: A well-defined high-level Project Overview Statement
Process Description: Gathering Business Requirements
The customer takes a more proactive role in the SCRUM project. Therefore, one or more requirements
gathering tools and techniques may be utilized depending on the comfort level of the Product Owner.
Available techniques in order of effectiveness may include:
[1] User stories
[2] Business process design
[3] Use cases
Deliverable: Business requirements gathered utilizing tools and techniques:
Deliverable: A prioritized list of functions and features
Process Description: The Project Overview Statement
The Project Overview Statement is a simple form used for documenting all requirements gathered. Essentially, this document is
developed at the end of the requirements gathering process of the Initiation (scoping) phase and serves as
a guide and baseline for the project as it moves into to the Planning Phase.
Deliverable: A project overview statement of requirements gathered
Process Description: Defining the Required Functions
In SCRUM, the Requirements Breakdown Structure (RBS) is the generated through the exercise of
defining the functions. These functions (and/or sub-functions in larger projects) define the Product
Backlog, which is a prioritized list of functions and features previously identified by the Product Owner (or
customer) that have not yet been integrated into the solution. Invariable, the contents of the Product
Backlog evolve as functionality is deployed and the discovery and learning emerging functions is
realized.
Deliverable: A defined Requirements Breakdown Structure (RBS)
Process Description: Prioritizing Defined Functions
The development of a prioritized list of functions is most effectively achieved around the concept of
business value added. The standard used may be as simple as applying the strategy of MuSCoW:
Mu = Must have functionality
S = Should have functionality
Co = Could have functionality
W = Wouldn't it be nice that the functionality has or is based on a weighted evaluation criteria.
Essentially, any selection criteria for functionality should foster a customer-centric approach.
Deliverable: A prioritized list of customer-centric functions
Project Phase: PLANNING PHASE
Process Description: Current Product Backlog
The Product Owner, most likely customer, in SCRUM is responsible for coming up with the list of
functions and features that should comprise the final solution. Because of the Product Owner's
continuous involvement in the solution demo processes, the list may change notably in future
iterations.
Deliverable: A list of functions and features for the final solution
Process Description: Prioritized Backlog
The Product Owner works closely with the SCRUM team in prioritizng the functions and features for the
current product backlog. Dure to the fact that there are no established protocols or method for managing
prioritization, other than the criteria prescribed by the Product Owner, the MuSCoW approach described
earlier is quite appropriate.
The SCRUM team identifies the features and functions from the prioritied list it it considers doable during
the 30-day upcoming Sprint period.
Deliverable: Prioritized functions and features for the Product Backlog
Process Description: Sprint Backlog
During the last half of the Sprint Planning Meeting the team establishes a high-level plan which describes
their strategy for completing the work assigned to the upcoming Sprint period. That plan contains a list of
the activities that must be accomplished in order to consider the Sprint Backlog completed.
Further decomposion of the functions and features of the Sprint Backlog will allow the team the ability to
define specific tasks to be selected as work assignments by the SCRUM team. Any necessary and
appropriate activity sequencing may be outlined in the plan.
Deliverable: A high-level plan to complete the Sprint backlog
Project Phase: LAUNCHING PHASE
Process Description: Launching the SCRUM Phase
Customer-Driven Tasks:
- Generate the Product Backlog list
- Participate in a Sprint Planning Meeting
Team Tasks:
- Plan initially on how the deliverables will be realized
- Establish the rules of engagement
Deliverable: Product backlog List
Deliverable: Preliminary plan for deliverables
Deliverable: Rules of engagement
Project Phase: MONITOR & CONTROL PHASE
Process Description: Monitoring and Controlling Sprint Backlog
The purpose of this process is to provide an understanding of the progress of the project so that timely
corrective actions can be implemented if and when performance deviates notably from plan. A simple
metric of value can provide a good measure of progress. In the Sprint Planning Meeting the team should
have established estimates for the duration (or effort) required to complete each feature in the upcoming
Sprint. The metrics, tools, and techniques described in the article
"SCRUM, An Agile Approach"
should help in developing these measures.
Deliverable: Labor or time parameters
Deliverable: Efficiency measures
- Estimated duration vs. Actual duration
- Cumulative actual vs. Cumulative estimate
- Productivity reports on the percentage of Sprint backlog (hours of duration) vs. percentage of working
hours
- Productivity reports on the percentage of features implemented vs. percentage of features documented
Project Phase: CLOSING PHASE
Process Description: Sprint Planning Meeting for Lessons Learned
The Sprint Planning Meeting provides an opportunity to the Product Owner to meet with the Sprint Team.
The main input for this meeting is the most recently prioritized Product Backlog. The Product
Owner and the Sprint Team work together to decide how much of that prioritized list can realistically be
completed in order to produce deliverables in the next 30-day Sprint. Questions may include:
- How do you negotiate changes in priority without affecting dependencies on functions or features?
- How do you avoid over-estimating the size of the next Sprint Backlog?
Deliverable: A preliminary plan for meeting deliverables for the upcoming Sprint Backlog
Process Description: Sprint Lessons Learned
During the Sprint Planning Meeting, the Sprint Team must decide how it can accomplish eachSprint
Backlog within the allotted 30-day time box. This could evolve as a formal or informal plan. As the team
migrates from one Sprint to another, it develops an acumen for creating the plan and gains the synergy
necessary to attain a higher level of proficiency.
- Each team member should be encouraged to share their progress with the assigned work.
- Team members must be encouraged to admit slow progress and the need for assistance.
Deliverable: Project document of Sprint lessons learned
Process Description: Project Completion Lessons Learned
Future projects adopting the Iterative SCRUM strategy will benefit tremendously from an archive
of complete documentation of lessons learned from past projects. Historic information from these
documents are invaluable and should be accessible to SCRUM Product Owners.
Deliverable: Documentation of project lessons learned