RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Introduction to Scrum : Page 2

Scrum teams use an empirical approach to adapt to changing requirements and priorities, with a focus on delivering working software to their customers frequently.

Process Overview
Scrum projects are managed in short iterations (Sprints) where the team works on the most important items of the project, as defined by the Product Owner, and delivers potentially shippable code at the end of each iteration. Everything in Scrum revolves around Sprints. Figure 1 shows the basic skeleton of the Scrum process, including key components such as the Product Backlog, the Sprint Backlog, the Sprint, and the Daily Meeting. The following sections chronologically describe what happens in the life cycle of a project using Scrum. Table 1 shows a summary of these steps along with the goals and responsibilities of everyone involved.

Figure 1. Scrum Process Overview: Here's the basic Scrum process skeleton, showing the key components.

Table 1. Scrum Process: Here are the major checkpoints for a team using Scrum.





Sprint planning meeting

4-8 hours

Entire team (Product Owner, ScrumMaster, business analysts, developers, QA)

Select from Product Backlog features to develop in the next Sprint. The result is called the Sprint Backlog. Come up with an initial plan to carry out the Sprint Backlog.


2 weeks

(or 30 days)

Entire team

Team works on Sprint Backlog. Result is potentially shippable software.

Daily meeting

15 minutes

(every day for the duration of the Sprint)


Entire team


Team members synch up with each other, review progress of the Sprint, and identify roadblocks.

Sprint retrospective meeting

1 hour

Entire team

Team members debrief how things went in the Sprint and discuss potential improvements for future Sprints.

Sprint Planning
Before a Sprint starts, the Product Owner (with the help of the ScrumMaster) reviews the list of all new features, enhancements, change requests, and any bug reports accumulated over time to decide which ones are most immediately important. If this is a new project, the list includes the features that the new system must provide. The entire list of items is called the "Product Backlog," and each item must include a description of what is requested, the priority for the business, and ballpark estimates for completing the item. It's the Product Owner's job to make sure this list is always up to date.

Scrum gives the Product Owner a large degree of control during the life of a project, letting the owner change priorities at every planning meeting (every two weeks or every 30 days depending on the size of your Sprint).

Scrum's practices and guidelines work because they address the most important component of software development: people and their interactions.
Because Product Owners represent the business, they typically have an idea of what customers want and what needs to be delivered first. Armed with this knowledge and preliminary estimates, the Product Owner selects a subset of items from the Product Backlog for consideration in the Sprint planning meeting.

The Sprint planning meeting has two parts. During the first half of the meeting (the first 2-4 hours) the Product Owner describes the features to the Scrum team to be implemented during the next iteration. Developers and QA ask questions to the Product Owner to come up with "good enough" estimates for each item. This is not a design meeting. The fact that this is a short meeting forces the team not to spend too much time overanalyzing each item. The ScrumMaster helps to keep this meeting focused and within the agreed-upon time.

Once estimates have been provided by the team, if there is more work estimated than time available in the Sprint, it is the job of the Product Owner to decide which Product Backlog items will be removed from the Sprint and which ones will be kept. It is very important to keep no more items than developers believe they can complete. It is also important to let the Product Owner (and not the developers) decide which items should be kept on the Sprint. In short: the development team estimates, but the Product Owner prioritizes.

As tempting as it might be to extend the duration of a Sprint "just a few more days" to make room for and squeeze in a few more items, Scrum practitioners recommend that you keep the Sprint size fixed, a process called "time boxing." Time boxing forces the Product Owner to make choices and focus on high priority items rather than trying to include every possible feature in one iteration. The ScrumMaster enforces this practice during the planning meeting. Remember that Scrum is iterative; there will be more iterations. If the items left out are still very important, they will come to the top of the list in the next Sprint planning meeting.

Items kept on the Sprint are called the Sprint Backlog. These items will be the focus of the team for the duration of the Sprint. During the second half of the Sprint planning meeting (the last 2-4 hours) the team comes up with a plan to carry out the items in the Sprint Backlog. For example, the team might break down some of the items into smaller blocks, so that multiple developers can work on an item, decide how the features are going to be tested, what features depend on each other, and which ones should be handled first on the Sprint.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date