r2 - 16 Jun 2010 - 09:41:02 - KevinVlaanderen

SCRUM Planning Phase

Introduction
Process description
Example
Further reading

Introduction

The software and systems development industry has always known a stable growth. Since the introduction of the Internet, more and more (web) applications have been developed by a lot of companies, whose size varies from five employees to ten thousands of employees. Developing software and systems, people (and their companies) always have tried to find and adapt a development process or methodology that streamlines their activities in an efficient and advantageous way. A more recent trend is that (especially software) companies have to be able to cope with unforeseen changes in the development process – and respond adequately. The recent tendency towards Web 2.0 web applications is an example of a characterization of this trend: the software market consists of a lot of (rapidly changing) companies, and many enter and leave the market. Google, Netvibes, del.icio.us, Digg and last.fm are examples of such companies. In order to cope with unforeseen changes, the development process or methodology used must be flexible and recognize those changes. SCRUM is methodology that tries to manage the unpredictable factors and control the risks within the (software) development process [1]. This article mainly focuses on the Planning phase, one of the main phases of SCRUM. Firstly, the background and origins of SCRUM (and the Planning phase) are described. Then, the (activities and concepts of the) SCRUM Planning phase process will be described more detailed. Thirdly, situational factors of the methodology will be identified and a simpler version of the Planning phase will be presented. Next, the usage of the methodology is described. The final section of this article, ‘Further Reading’, contains a list of literature references that can be of value if more elaborate information on the SCRUM methodology or its Planning phase is needed.

Background and origins

As mentioned in the previous section, many attempts have been made to create a satisfying methodology for the software development process. These attempts have encountered the following problems:

- Many of the development processes are uncontrolled. The inputs and outputs are unknown or vaguely defined
- Environmental input (requirements) can only be taken into consideration at the beginning of the process – complex change management procedures are required thereafter

Attempts to impose a detailed methodology model on the development process have not worked, because the development process is not defined completely. Acting as if the development process is completely defined (as various methodologies do), results in being unprepared for unpredictable developments. For example, the Waterfall methodology approaches the development process in a quite linear way, which has as a consequence that it does not define how to cope with unexpected input (or output) in any of the phases of the development process. If an unexpected change occurs in one of the phases, it is hard to go back to a previous phase – because of the structure of the model. See figure 1.

Another often-used methodology is the Spiral methodology [4]. While this methodology has a less linear nature than the Waterfall methodology (the various development phases are visited in a spiral way), each of the phases consists of linear, explicitly defined processes. The Iterative methodology is an improvement over the Spiral methodology. However, its approach still expects that the underlying development processes are defined, linear and that the outcome of each of the processes is predictable. But unpredictable results occur throughout projects. To respond adequately to unforeseen changes and developments, a flexible methodology is needed. While Waterfall and Spiral methodologies set the context and deliverable definition at the start of a project, SCRUM and Iterative methodologies initially plan the context and broad deliverable definition, and then evolve the deliverable(s) during the project based on the environment. The SCRUM methodology is a management, enhancement and maintenance methodology for an existing system or production prototype. SCRUM is often used within systems or software development companies and can be seen as an enhancement of the iterative and incremental approach to delivering object-oriented software. The methodology was mainly developed by Ken Schwaber, in 1995. It assumes existing design and code (which is basically always the case in object-oriented development, due to the presence of class libraries). SCRUM acknowledges that the underlying development processes are incompletely defined and uses control mechanisms to improve flexibility. The methodology consists of only two defined phases, where all processes, inputs and outputs are well-defined. These phases are Planning and Closure, as shown in Figure 2. The Sprint phase is an empirical process. Many of the processes in the sprint phase are unidentified or uncontrolled, and their outcome is often unpredictable. The Sprint phase is treated as a black box that requires external controls.

Sprints are nonlinear and flexible, and are used to evolve the final product. The planning phase embodies the preparation of the Sprints . For example, a new release of the specific software product or service is defined, based on a backlog (list of product functionality requirements) that is created in the beginning of the Planning phase. Furthermore, an estimation of its schedule and cost are made. A much more detailed description of the Planning phase is given in the section ‘Process Description’. As depicted at the figure above, the Planning phase must be completed before the Sprint phase starts.

Process description

In this section, the SCRUM Planning phase is illustrated by a PDD. The Planning phase is divided in various activities and sub activities. The Planning phase starts with the ‘Backlog development’ activity. Within this activity, a backlog is created (or retrieved when a backlog is already available from a previous release or project), requirements are prioritized and an updated backlog is delivered. The next activity, ‘Delivery definition’, identifies the releases, functionality to be implemented per release and resources that are needed to implement the functionality corresponding to a certain release. Furthermore, delivery dates are planned for each release. In the next activity (‘Release selection’), a release for immediate development is selected, based on the current project status (amount of resources). Within the next activity, backlog items that correspond to the functionality to be implemented for the release selected at the previous activity (‘Release selection’) are identified, as well as product components that must be changed to implement the identified backlog items into the selected release. The ‘Project teams definition’ activity is executed to divide functionality over the people that are available. Furthermore, project teams are defined. Risks and risk controls are identified within the next activity, ‘Risk assessment’. When that activity is completed, the backlog items are reviewed and adjusted if needed. Also, the product packets mapping is adjusted if needed. Within the next activity, ‘Tools validation’, available tools (for development, design, etc.) and infrastructures are identified and validated. The next activity is called ‘Cost estimation’. Main activities (within the project) are identified and costs per activity are estimated in this (SCRUM Planning phase) activity. The final activity of the SCRUM Planning phase is ‘Approval verification’. Within this phase, approvals and funding are identified and verified. All activities are listed in an activity table. As shown in the Process-Deliverable Diagram, the main deliverables of the SCRUM Planning phase are the Backlog and one or more Releases. A Backlog consists of one or more Backlog Items. Each Backlog Item has a requirement definition, priority, cost estimation and an indication of the resources needed (people, time, etc.). A Release also consists of one or more Backlog Items. When one or more Backlog Items are completed, they form a new Release of a software product, for example.

Activity table

Activity	Sub activity	Description
Backlog development	Get currently known backlog / Create new backlog	Get or create a list of Items (requirements) that are not (completely) addressed by the current product Release
	Prioritize requirements	Sort the Backlog Items on their importance. The most important requirements need to be fulfilled first
	Update backlog	Save the new prioritization to the Backlog
Delivery definition	Identify releases	Estimate what amount of Releases is appropriate for the current project (product)
	Identify functionality	Identify which Functionality will be implemented at which Release
	Identify resources	Per Release, estimate the amount of people and time that will be needed to implement the Functionality for that release
	Plan delivery dates	Based on the estimation of the previous sub activity, plan the delivery date for each Release
Release selection	Identify current status	Identify the amount of people, time, etc. that are currently available
Release selection	Select release	Based on the previous activity and sub activity, select the Release that is most appropriate for immediate development
Product packets mapping	Identify backlog items	Select the Backlog Items that correspond to the Functionality to be implemented for the Release selected at the previous activity (check the delivery definition).
Product packets mapping	Identify product components	For each Backlog Item, identify the product components that must be changed to implement this Backlog Item into the selected Release
Project teams definition	Divide functionality	Based on the product packets mapping and the delivery definition, divide the Functionality to be implemented over the people that are available, corresponding to their respective functions.
Project teams definition	Define project teams	Define project teams based on the Functionality division at the previous activity.
Risk assessment	Identify risks	Identify the risks of the Functionality development / implementation of the current Release
Risk assessment	Identify risk controls	Per risk, identify appropriate controls that are available to limit the risk
Backlog review	Backlog item review (risk mapping)	Identify which Backlog Items are affected by the risks identified at the previous activity
	Backlog adjustment	If needed, adjust the Backlog Items determined in the previous sub activity based on the identified risks
	Product packets mapping adjustment	If needed, adjust the determined product packets based on the identified risks
Tools validation	Identify tools	Identify which Tools (development, design) and infrastructures are available that are needed for the implementation of the Functionality of the current Release
Tools validation	Validate tools, infrastructures	For each available Tool and infrastructure, check to which extend it is valid and applicable for the implementation of the Functionality of the current Release
Cost estimation	Identify main ‘activities’	Determine which activities of (and materials needed for) the Functionality implementation will require significant amounts of money (marketing, training, rollout, etc.)
Cost estimation	Estimate costs	Estimate the costs for each of the activities determined in the previous sub activity
Approval verification	Identify approvals and funding	Identify management approval and funding
Approval verification	Verify approvals and funding	Verify the management funding and each of the management approvals

Concept table

Concept

Description

Backlog

A list of requirements that are not adequately addressed by the current product release. Bugs, defects, customer requested enhancements, competitive product Functionality, competitive edge Functionality, and technology upgrades are Backlog Items (Schwaber, 1995)

Item

The concepts of which a Backlog consists. Multiple Items can form a Release (an Item often represents a requirement for an upcoming Release). (Schwaber, 1995)

Attribute name	Explanation
Requirement definition	Definition of the requirement with which the Item corresponds
Priority	Importance of the Item, in relation with the other Items
Number of people needed	The amount of people that are needed to implement the Functionality represented by this Item
Hours needed	The amount of hours that are needed to implement the Functionality represented by this Item
List of activities	List of ‘extra’ activities (distinct from the Functionality that has to be implemented) that have to be completed for the Release this Item belongs to
Cost estimation	An overview of the costs for each of the activities in the List of activities

Release

Backlog Items that at a point in time represent a viable

release based on the variables of requirements, time, quality, and competition (Schwaber, 1995)

Attribute name	Explanation
Delivery date	The date on which the Release must be completed. All Functionality represented by the Items of the Release must be implemented.

Product Packet

Product components or objects that must be changed to implement a backlog Item into a new release (Schwaber, 1995)

Project team

A team used for grouping people based on a common function. Members of a team usually belong to different groups, but are assigned to activities for the same project (reference.com)

Functionality

A useful function within a computer application or program (reference.com)

Risk

Risks affect the success of the project and are continuously assessed and responses planned. Other controls are affected as a result of Risk assessment (Schwaber, 1995)

Attribute name	Explanation
Severity	The extend to which the Risk is undesirable
Items affected	A list consisting of one or more Items that are affected negatively by the Risk
Response initiated	A flag representing if response to the Risk has been initiated

Tool

An application program, often one that creates, manipulates, modifies, or analyzes other programs (reference.com)

Attribute name	Explanation
Type	Represents the type of the Tool. For example, a Tool can be used for design, development or evaluation purposes (depending on the Functionality represented by the Item).
Passed Validation	A flag representing if the Tool has passed the ‘Tools validation’ activity

Example

As discussed earlier, the backlog forms an important element of the SCRUM Planning phase. For example, this is reflected by the various activities of this first phase of the SCRUM methodology: the first activity embodies the development (or obtainment) of the backlog. When the end of the Planning phase is nearing, the backlog is reviewed. If it within the reviewing activity appears that the risk for one or more backlog items is too high, the backlog is adjusted. At the end of the SCRUM Planning phase, the first version of the backlog has been constructed. The backlog often is seen as the main deliverable of this phase. During the subsequent phases of the SCRUM methodology, the backlog is also frequently used. For example, the backlog forms an essential part of the characteristic Sprints. During the SCRUM meetings mentioned at the ‘Situational factors’ section (‘project team size’), the backlog is used to review the progress of the project. At each SCRUM meeting, the backlog is updated with new status information. Those meetings are the appropriate moments to update the backlog, because in that way the backlog always represents the current status of the project. This limits the chance that different people are referring to different statuses or versions of the product. At the end of the project, in the Closure phase, the backlog can be used to review the history of the project. For example, backlog items, decisions and unexpectedly occurred problems can be discussed. Furthermore, a time evaluation may be done to better meet (comparable) deadlines in future projects. A backlog basically consists of a list of backlog items, each item representing functionality (requirements) of the product. The backlog items often are divided over the planned Releases and various Sprints and per item, a deadline is defined and a project team is attached.