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