SCRUM Phases and Underlying Processes
An Agile Life Cycle Model
By Contributing Editor
Project Phase: SCOPING PHASE
Process Description: Idea Creation
In a SCRUM project, the Product Owner (voice of the customer - VOC) begins the process by defining a new or enhanced
solution. The Product Owner develops a high-level description in the form of a Project Overview Statement (POS). If
necessary, a Condition of Satisfaction (COS) statement may complement the Project Overview Statement to ensure a well-
defined project statement is produced and agreed upon by key stakeholders.
Deliverable: A Condition of Satisfaction statement
Deliverable: A new or enhanced solution defined
Process Description: Gathering Requirements
The customer (Product Owner) has 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 (workflows, etc)
[3] Use cases
Deliverable: Business requirements gathered utilizing tools and techniques:
Deliverable: Business rules, logic, and acceptance criteria
Process Description: The Project Overview Statement (POS)
The POS 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 are realized.
Deliverable: A defined Requirements Breakdown Structure (RBS)
Deliverable: A detailed Requirements Document (living document)
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 concept of MuSCoW (or MosCow):
Mu = Must have functionality
S = Should have functionality
Co = Could have functionality
W = It would be nice if the functionality has, or is based on weighted evaluation criteria. Essentially, any selection criteria for
functionality should foster a customer-centric approach.
Deliverable: A prioritized list of customer-centric functions and features
Project Phase: PLANNING PHASE
Process Description: Product Backlog List
The SCRUM Product Owner (or VOC), is responsible for producing the list of functions and features that should comprise the
final solution. Because the Product Owner is continuously involved in the solution delivery processes, the list may change
significantly in future iterations.
Deliverable: An evolving list of functions and features (stories) for the final solution
Process Description: Prioritized Product Backlog
The Product Owner works closely with the SCRUM team in prioritizng the functions and features for the current product
backlog. Due 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 above is quite appropriate.
The SCRUM team identifies the features and functions from the prioritied list it considers doable during the (15-30 days)
upcoming Sprint time-box.
Deliverable: Product Backlog with prioritized functions and features (stories)
Process Description: Sprint Backlog Items
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 items
Project Phase: LAUNCHING PHASE
Process Description: Launching the SCRUM Phase
The launching phase is really the high-level kick-off process in order to receive approval from key stakeholders to initiate
the SCRUM project. This phase re-iterates the objectives of the project, re-visits the scope, and establishes the protocols for
supporting the project. This phase also includes the Planning Meeting for the first Sprint.
Customer-Driven Protocols discussed:
- Generate the Product Backlog list
- Participate in Sprint Review and Retrospective meetings
- Participate in Sprint Planning meetings
Team-Focused Protocols discussed:
- Initial plan on how deliverables will be realized
- Established the rules of engagement
- Commitment to items from the Product Backlog List
Deliverables:
- Product backlog List
- Sprint backlog items
- Preliminary plan for deliverables
- 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 Review Meeting
At the end of each Sprint, the "Sprint Review Meeting" is conducted along with the entire team, the Product Owner and the
SCRUMMaster. Other stakeholders are invited as optional guests. During the review meeting, the team reviews the work
completed and pending. The SCRUM team presents the finished component to the stakeholders to be reviewed as a
demonstration. Incomplete deliverables cannot be demonstrated. Normally, depending on the complexity of the
component, there should be appropriate preparation made, and time set aside for this meeting.
Deliverable: A demonstration of the completed component that meets the established objectives
Process Description: Sprint Retrospective Meeting
After the Sprint Review meeting, the Sprint Retrospective meeting provides an opportunity to the SCRUM Master to meet
with the Sprint Team.
The objective of this meeting is to candidly discuss the performance of the team in delivering
the objectives of the closing Sprint. The following questions should be raised and discussed:
- What did we do right, which can be recommended for other projects?
- What did we do wrong, and what suggestions do you have for improvement?
- What could we do better, and what enhancements may be introduced to the process?
Deliverable: A list of suggestions for continuous process improvement
Process Description: Sprint Planning Meeting for the Upcoming Sprint
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 (15-30 days) 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 (15-30 days) 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 developing 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 ofcomplete documentation
of lessons learned from past projects. Historic information from these documents are invaluable and should be accessed by
future SCRUM Product Owners.
Deliverable: Documentation of Project lessons learned