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