An introduction to SCRUM

Hi  !

Being aware of the SCRUM framework is a recurring trend. Whether you’re looking to pursue a career in management or you are just curious, this article can be a good starting point.

What is SCRUM ?

Before going into SCRUM we should give a step back and understand what AGILE stands for.

A step back…AGILE

Agile is a set of software development methods based on small, iterative and incremental developments. Agile core values and principles are described since February 2001 on the Agile Manifesto.

Agile is quite different from the Waterfall method of software development as can be seen by the picture below.


The Waterfall Model is based on a big software development life-cycle that encompasses all the above stages from the Conception to the Deployment whereas in the Agile model, each iteration encompasses all phases.

Shorter iteration cycles mean less risk towards the final delivery and greater customer satisfaction as customer and developers work more frequently together to achieve a final desired result. Using the classic “swing on a tree” analogy…


Agile’s iterative development approach is more likely to deliver what the customer really wants!

Understanding SCRUM

SCRUM together with Extreme Programming(XP),  Feature Driven Development (FDD),  Lean and others is a part of many well known agile software development methods/frameworks. The key principle of SCRUM is its recognition that during a project the customers can change their minds about what they want, and the team should be focused on delivering quickly and responding to emerging requirements.

While the Agile methodology can be applied to product development not only in the software industry but in other industries as well, SCRUM is specific to software development.

SCRUM is not a methodology. It simply provides structure, discipline and a framework for Agile development.

How can we use it ?

On the following 5 steps below I will try to explain what it takes to immediately start adopting SCRUM at your organization. I’m going to use the image below as reference to explain each of steps.


Step 1 – Setting up a team

Generically the team includes Users, Stakeholders, Developers, the Scrum Master and the Product Owner however, in SCRUM terminology, only 3 roles are considered : the Product Owner, the Scrum Master and the Development Team. Note the conspicuous absence of a Project Manager ! That is in part because this role is partially taken by the Scrum Master, and also because SCRUM teams are self-organizing and choose how to best accomplish their work rather than being directed by others outside of the team.

The PRODUCT owner

The Product Owner is the  sole person responsible for managing the content and ordering of the Product Backlog by representing the interests of the stakeholders, and ensuring the value of the work the Development Team does. 

Managing the product backlog may include some or all of the following activities:

  • clearly express the product items
  • ordering the items of the product backlog to best achieve goals and missions
  • optimizing the value of the work the development teams performs
  • ensuring the transparency and visibility of the Product Backlog so that the SCRUM team knows on what to work next
  • ensures the development teams understands the items on the product backlog

The SCRUM master

The SCRUM master is the SCRUM’s version of a project manager. The SCRUM master is responsible for ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. It is also the role of the Scrum Master to help those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t.

The SCRUM master serves the Development Team, the Product Owner and the Organization in several ways including:

  • finding techniques for effective product backlog management
  • helping the scrum team to find clear and concise  product backlog items
  • coach the development team in self organization and cross-functionality
  • removing impediments to the development team progress
  • leading and coaching the organization in its SCRUM adoption
  • facilitating SCRUM events as requested or needed

A more complete description of the SCRUM master functions can be found on the website.


The development team is a cross-functional group of people responsible for delivering potentially shippable increments of Product at the end of every Sprint. Development teams are structured and empowered by the organization to organize and manage their own work,  thus optimizing their overall efficiency and effectiveness.

The suggested development team size varies between 3 and 9 elements. Teams smaller than 3 elements may encounter skills constraints whereas teams larger then 9 require too much coordination effort.

Step 2 – Defining the Product Backlog

The Product Owner is responsible for defining a Product Backlog listing all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. It is also the Product Owner responsibility to tell the team which items from the Product Backlog should be addressed on the next sprint.However it’s the Development’s team responsibility to decide what they can commit to. Committed items become the Sprint Backlog.Backlog items have the following attributes: description, order, estimate and value.

As requirements never stop changing, a Product Backlog is a living artifact. Unlike the Product Backlog, items on the Sprint Backlog are closed during the duration of the sprint.

Step 3 – Defining the Sprint Backlog

As we have have seen before, the Sprint Backlog are the work items the Development Team is committed to do . The Sprint Backlog also includes a plan to deliver the product Increment and realizing the Sprint Goal.

The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.

The product Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.

The Sprint Backlog plan must include enough detail so that the sprint progress can be seen on the daily scrum meeting. It most be possible at any point in time, to sum up the remaining work on the Sprint Backlog. At the end of a Sprint, the new Increment must be “Done” .

Often an accompanying task board is used to see and change the state of the tasks of the current sprint, like “to do”, “in progress” and “done. See picture below.


Step 4 – Executing the Sprint

A Sprint is a period of time(typically between 1 and 4 weeks) during which the Development team executes the Sprint Backlog. To assess progress,review issues or problems every day a Daily Scrum Meeting is held. Only the Development Team and the Scrum Master attend this meeting.

The Daily Scrum Meeting is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours.The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog.

A Sprint BurnDown Chart is typically built during this step to show the progress towards completion of pending items. A BurnDown Chart is a simple but very effective technique that is used to keep track of work and to determine if its going to meet upcoming deadlines. For every sprint, you calculate the amount of time available, and the amount of work to be completed during that time. Each day, you plot on a graph how much you have completed. In an ideal project, what you should get is a nice downward line heading towards zero by your last project day. You can see an example of a BurnDown Chart chart on the picture below.


Step 5 – Finishing the Sprint

At the end of the Sprint time, the Sprint ends whether all items/tasks are completed or not.It will up to the Product Owner to review what has been done in the Sprint and decide to release it or not. The Increments marked with “Done” and the others not completed will be discussed during the Sprint Review meeting.The definition of “Done” may vary from one Scrum team to another, but must be consistent within one team.

The Sprint Review Meeting is an informal time-boxed event during which the Scrum Team and stakeholders collaborate about what was done in the Sprint
The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint.

After the Sprint Review and prior to the next Sprint Planning, a time-boxed Sprint Retrospective Meeting must be held.A Sprint Retrospective Meeting is where team members discuss what went well and what needs improvement. Scrum makes a point of capturing all the valuable lessons that can be learned from a project, but which too often get forgotten about. These lessons get put into action straight away of course, because following a retrospective will be the next sprint in the project. So it is an opportunity for improvement as the project goes on.

Final thoughts

SCRUM is obviously a very practical and down-to-earth framework. It focuses on individuals over processes. After years of working typically with the waterfall methodology, it is easy to see that adopting SCRUM will definitely imply a change in the way Project Managers, Testers and Developers work. For the me, the agility and responsiveness gained by adopting SCRUM, will far outweigh its risks.


[1] HubPages ; The ten minutes SCRUM terminology ;

[2] Wikipedia ; Agile Software Development  ;

[3] Sr’s Technology blog; Agile Development using SCRUM;

[4] Wikipedia; Scrum software Development ;

[5] Scrum Methodology; Scrum training series ;

[6] Slideshare ; Working with SCRUM;

[7] ; Scrum Guide ;

[8] Scrum Alliance ; An example scrum masters checklist ;