Scrum Framework

14/10/2015

Balachandar S
Telecom
balachandar3.s@tcs.com
Table of Contents

1. Introduction .............................................................................................................................................................. 4
1.1 Purpose of the Document ................................................................................................................................. 4
1.2 What is Agile?.................................................................................................................................................... 4
1.3 Agile Methodologies ......................................................................................................................................... 4
2. Scrum ........................................................................................................................................................................ 5
2.1 Why Scrum is efficient ...................................................................................................................................... 5
2.2 Roles and Responsibilities ................................................................................................................................. 6
2.2.1 The Scrum Team .............................................................................................................................................. 6
2.2.2 How Scrum works without Project manager? ................................................................................................. 7
2.3 Product Backlog ...................................................................................................................................................... 7
2.4 Scrum Burndown Chart ........................................................................................................................................... 8
Burndown Chart with completion estimation .......................................................................................................... 8
3. Sprint ........................................................................................................................................................................... 10
3.1 Sprint Meetings ..................................................................................................................................................... 11
3.2 Sprint Backlog........................................................................................................................................................ 12
3.3 Sprint Burndown Reports...................................................................................................................................... 13
4. Release planning for Scrum projects .......................................................................................................................... 15
4.1 Feature Driven Release plan ................................................................................................................................. 15
4.2 Date Driven Release Plan ...................................................................................................................................... 16
5. Large Scale Scrum Projects ......................................................................................................................................... 18
5.1 Scrum of Scrum ..................................................................................................................................................... 18
6. Scrum Tools ................................................................................................................................................................. 19
7. Myths about Scrum ..................................................................................................................................................... 20
8. Conclusion ................................................................................................................................................................... 21

2
Table of Figures

Figure 1 - Scrum Framework ............................................................................................................................................. 5

Figure 2 - Product Backlog ................................................................................................................................................ 7
Figure 3 - Scrum Burndwon Chart ..................................................................................................................................... 8
Figure 4 - Scrum Burndown Chart with estimation .......................................................................................................... 9
Figure 5 - Sprint Burndown Report ................................................................................................................................. 14
Figure 6 - Feature Driven Release plan ........................................................................................................................... 15
Figure 7 - Date Driven Release Plan ................................................................................................................................ 16
Figure 8 - Scrum of Scrum ............................................................................................................................................... 18
Figure 9 - Jira tool............................................................................................................................................................ 19

3
1. Introduction

1.1 Purpose of the Document

The purpose of this document is to give a brief overview on the SCRUM framework for beginners to help them work
in Agile projects using SCRUM framework or take up certification on SCRUM

1.2 What is Agile?

Agile refers to a number of software development methodologies/frameworks which uses iterative approach of
software development. The requirements and solutions evolve through collaboration between closely working self-
organised teams in these frameworks and the final product is delivered after several phases of learn and adapt
methodology

1.3 Agile Methodologies

Different projects follow different agile methodologies. Few of the well-known Agile methodologies are as below:

 Scrum
 Kanban
 Lean
 Extreme Programming (XP)
 Crystal
 Dynamic system Development method (DSDM)
 Feature Driven Development (FDD)

4
2. Scrum

Scrum is a lightweight agile software development framework which can be used for any small/larger projects by
managing and controlling the iterative/incremental process. It is referred to as lightweight framework as the
overhead of the process is kept as small as possible to maximise the productive time in achieving the final goal.

Note: The name SCRUM emerged as a rugby analogy where a self-organising team move towards the field - together

2.1 Why Scrum is efficient

Scrum is more efficient when compared to the tradition waterfall or other software development models. It follow
the approach of incremental software development which remains flexible all the time and can be changed in
controlled manner without additional costs and jeopardizing the large amount of completed work.

The below diagram depicts the SCRUM framework along with the different roles/people involved in the framework

Figure 1 - Scrum Framework

5
2.2 Roles and Responsibilities

Scrum Master
Scrum Product Owner
• Facilitates various Scrum events
• Managing the SCRUM product backlog
• Coach the Scrum Team
• Release management
• Remove impediments for the Scrum
• Stakeholder management
team
• Work closely with SCRUM team
• Ensure Efficient communication between
Scrum team and Product owner

The Scrum Team

• Creation of Sprint backlog
• Highlighting the status, needs &
impediments in daily Scrum meeting
• Ensuring delivery of shippable product at
the end of each Sprint
• Updating the remaining effort at the end
of each day in a sprint

2.2.1 The Scrum Team

 A Scrum team is a cross functional team which represents different disciplines such as developers, testers,
user experience and all other required participants
 The Scrum team always follows a common goal and adheres to the same norms & rules
 The Scrum team is autonomous and empowered to take decisions which is protected from external
disruptions by Scrum Master
 The Scrum team is always small in size and is well balanced

6
2.2.2 How Scrum works without Project manager?

In Scrum framework, the responsibilities of a project manager are distributed among the Scrum Product owner and
the Scrum master.

The roles of the Scrum master involving in the initial phases of the project for planning makes it easier to decide on
requirements, release & costs and also to interact with Product owner with much ease & better approach.

The Scrum Product owner interacts with end customer, marketing & services and collects the overall
functionalities/products to be delivered for the project.

2.3 Product Backlog

The Scrum product owner collects the various requirements from the end customer and creates a product backlog. It
simply contains the to-do list for the project and replaces the traditional requirement specification artefacts

• Product backlogs represents the higher

level to do list for the project
• The effort of all the items can be
represented in number sizing (1-10) or
shire sizes(S, M, L ,etc..) as shown in the
picture
• The items in the product backlog are
prioritized and ordered accordingly
• Only one item in the product backlog is
of top priority and will have granular
details
• The remaining items can be broken
down/ details can be added in the later
phase/successive sprint of the project as
required
• The requirements/items in the product
backlogs are not frozen and can be
added/deleted/modified after each
sprints as required by the Product
owner
• Any entries in the product backlog
always adds value for the customer
Figure 2 - Product Backlog

7
2.4 Scrum Burndown Chart

The Scrum Burndown chart can be used to depict the remaining effort at the start of each sprint against the
remaining work at the last sprit/start of the project. It serves the purpose of tracking the status of the project to
work towards the delivery of solution on the expected timeline.

Figure 3 - Scrum Burndwon Chart

The above figure indicates a sample Scrum burndown chart. As the requirements/items in the product backlog can
be added at the end of the sprint, they are represented in the negative y-axis in the graph. Please note that the
number of backlogs completed in each sprint gets reduced in the positive y-axis at each sprint interval

The linear graph in the above figure represents the velocity (rate of progress) of the Scrum team

Burndown Chart with completion estimation

With the above graph, it is easy to estimate the completion of the project as shown below

8
 Figure 4 - Scrum Burndown Chart with estimation

Please note that the change in the product backlogs (negative y-axis) are also taken into account while estimating
the end date and hence this approach is more accurate

Note: The Scrum burndown chart can also be drawn as liner graph depicting the completion of the project work
against the estimated rate of completion. But, such graph will not depict the increase/decrease in the items of
product backlog and hence it will not be possible to predict the date of completion with such linear graphs.

9
3. Sprint

The activities performed to deliver each items in the Product backlog occurs within a Sprint. The duration of the
sprint may vary depending on the project.

The Sprint maintains a Sprint Backlog which are identified and broken down from the Product backlog to-do list.
Also, various meetings are held during the Sprit and at the end of the Sprint to track the delivery of product/item
as identified from the Product backlog. We will discuss them in detail
3.1 Sprint Meetings
Sprint Planning Meeting
• Each Sprint starts with 2 planning meeting –
WHAT & HOW meetings
• WHAT meeting is used to define the items in
Product backlog to the Scrum team by the
Scrum Product owner
• The items which can be completed in a
Sprint are identified and broken down into
small stories
• The Capacity of the team is also decided
during the WHAT meeting
• Goal of the HOW meeting is to identify the
tasks for the items of a Product backlog and
fill the Sprint backlog
• It is expected to estimate how long the
sprint can be completed with the above
information during HOW meting
Sprint Review Meeting
• Sprint Review meetings are held at the
completion of each Sprint Window
• The Product owner (PO) will check if all the
committed items of a Sprint are completed
and are implemented as expected
• Any items committed and not completed
in the Sprint window can be moved back
to the Product backlog to prioritize for
next sprints and to be informed to PO
• The participants of Review meeting
includes Product owner, Scrum master and
Scrum team. Customers and management
can also participate in the meeting if
required
11
Daily Scrum meeting
• Daily Scrum meeting are held within the
Scrum team to focus on the progress and
address impediments/challenges faced during
daily activities
• Daily Scrum meetings should be planned for
not more than 15 to 20 minutes and the key
updates/challenges are discussed
• The challenges/issues raised during the Scrum
meeting are recorded by the Scrum master
and need to be addressed/ resolved after the
Scrum meeting
• The Product owner may/may not be part of
the Scrum meeting
• It is mandatory that the Scrum master
arranges for the Scrum meeting every day and
ensure all the members of the team are aware
of the process of the meeting
Sprint Retrospective meeting
• Sprint Review meeting is followed by the
Retrospective meeting to analyse and improve
the process of the project
• During this meeting, all the team members
should focus on three things – (i)What went
well which can be continued as it is; (ii)what
didn’t and (iii) what improvements can be
done in the next Sprint
• The Retrospective meeting is integral part of
‘inspect and adapt’ process followed in Scrum
and with which team can deliver continuous
improvements in the successive Sprints
• The meeting can last for about 3 hours or
more and the participants includes The Scrum
Mater and The Scrum Team
3.2 Sprint Backlog

All the activities identified to complete the items in the Product backlog are stored as different entries in the Sprint
Backlog

12
 • The Sprint backlog has the items to be
completed on a Sprint and also the
assignees for each item
• It need to be updated on the daily basis
with the work done and the remaining
efforts at the end of the day
• Any new activities identified during the
Sprint window can be added to the Sprint
backlog any time during the Sprint
• The Sprint backlogs are used to determine
how much work is left in order to
complete/achieve the Sprint goal
• The Definition of Done (DOD) is used to
determine if the task on a Sprint backlog is
completed
• DOD: Definition of done is a checklist to
ensure only the true features are
delivered – in terms of both functionality
and quality
• The Sprint backlog can either be
maintained as an excel sheet or as cards
on a task board
• Though maintaining cards has its own
advantage of transparency and easy access
when the team is co-located, the excel
sheet is the possible way to use if the team
is spread across different locations

3.3 Sprint Burndown Reports

The Sprint Burndown Reports shows the progress within the Sprint with respect to the remaining efforts/ sprint
backlogs to be completed in the Sprint window.

13
It provides transparency about the current performance (burndown rate) and hence allows Scrum team to work on
estimates in achieving the Sprint goal in the remaining window

Figure 5 - Sprint Burndown Report

As shown above, all the remaining efforts for the particular day are collected and added to the graph to maintain the
report. The performance during the initial stages is acceptable to be lower than expected due to few challenges but
the gaps need to be gradually filled during the later stages of the sprint.

14
4. Release planning for Scrum projects

A high level release plan need to be created for all the Scrum projects. This will act as a guideline to track the
completion timelines of different functionalities/expectations.

The release plan can be created in 2 different ways depending on the project

4.1 Feature Driven Release plan

The releases are planned based on the features to be implemented for the project. The release may span across
more than 1 sprint until the requested feature is planned to be completed

We will see an example below to understand the Feature Driven release plan

Figure 6 - Feature Driven Release plan

15
 Time planning for the different Releases

1 – Consider a Sprint with 3 Velocities. Sprint length can vary depending on the project
2 – As per the above release goals, the first release should have the user enable to login & logout
3 – From the to-do list, it estimates to about 5 units/ velocity
4 – Hence, the first release can be completed in 2 Sprints
5- In a similar way, other Releases can be planned

4.2 Date Driven Release Plan

In date driven release plan, the release are planned based on the fixed time and the number of feature which can be
delivered with this release window need to be decided

Figure 7 - Date Driven Release Plan

16
Planning the tasks to be delivered for each Release

1 - As shown in the above example, the release window is fixed to be 6 weeks

2 - The velocity is determined to be 3 points per sprint and Sprint length is of 2 weeks
3 – Hence, 3 sprints sums up to 1 release for the project
4 – Considering the above points, 1 release can deliver -> 3 sprints * 3 velocity = 9 points
5- Hence, the below tasks can be planned for each release as below
• Release 1 - Priority tasks 1-5 (8 points)
• Release 2 - Priority tasks 6-7 (7 points)
• Release 3 - Priority task 8 (5 points)
• Release 4 - Priority task 9 (8 points)
• Release 5 - Priority task 10 (2 points)

17
5. Large Scale Scrum Projects

The success of the Scrum also lies in the number of people working in the team and it is always expected to be
smaller in size for effective communication and sprint planning.

In order to deliver a large project and to support the technical feasibility/ business decisions, the project team
cannot be kept small and different members of the team may need to work in different locations. Hence, it is
necessary to split the project into different Scrum team working in the same locations or distributed across different
locations.

The Scrum team can be divided in below 3 ways depending on the project need:

Multiple Teams in Same Location – All the Scrum teams are distributed in the same location

Multiple Teams in Different Locations – Each Team works from different locations but the members of each team
are based in the same location

Same Team in Multiple Locations – The members of the same team are located in different locations to address the
technical/ business dependency

5.1 Scrum of Scrum

In order to co-ordinate between the different Scrum teams, it is necessary to have Scrum of Scrum meeting which
usually takes place between the Scrum Masters of different teams

• Each Scrum team should have a

stand-up/daily Scrum meeting to
discuss on the progress/
impediments of the team
• The Scrum Masters then get
together for another Scrum
meeting and discuss the cross-
program risks on daily basis
• The updates are then passed to
each team
• The problems/ updates always go
up the chain and down the chain
all the times in the Scrum of
Figure 8 - Scrum of Scrum Scrum for efficient output

18
6. Scrum Tools

There are different types of Scrum tools available in the market for project management and issue tracking. Some
are free, some are paid and also there are tools called as Freemium through which we can use the distilled version of
the tool but to use all the features, we need to buy the tool.

Some of the well-known Scrum tools are listed below

 Jira
 Axosoft
 Scrumwise
 ScrumDesk
 Agilo
 Banana Scrum
 Daily-Scrum
 Fire-Scrum (open source)
 Ice Scrum (open source)
 Quick Scrum
 Scrum Dashboard (open source)

Figure 9 - Jira tool

19
7. Myths about Scrum

There are some misunderstanding and myths about Scrum framework such as it is more of satisfying the customer or
there is no need of documentation, etc… These are not right and one needs to have a clear understanding of Scrum
framework to have a positive result

1. Scrum is delivering the right software

Few team work towards satisfying the customer for each sprint and at the end it may result in a final product
which are of no use to the customer.

Scrum is more about Working Software and not Delighting the customer

2. Scrum requires Documentation

It is not right to say that Scrum does not need any kind of documentation.

Scrum framework needs documentation right from capturing the customer requirements till the point of
delivering the final product. The need for different documents depends on the project but it is necessary to
create and maintain required documents at each stages

3. Scrum is about self-organisation

Scrum is based on the principle of self-organisation and it requires facilitation and not management. Scrum
Master is not the boss in a Scrum team; rather he is a facilitator and works with the team

4. Definition of Done

It is very much essential for all the members in the Scrum team to be made aware of the Definition of Done.
Scrum is not about delivering the product on time but delivering the right product

5. Work on (only) one project

It is wrong to thing that Scrum Master can contribute to more than one project as his role is only on
facilitation of the Scrum team. The Scrum master should be committed to only one project and should
understand the in and out of the project. Hence, it is necessary for the Scrum Master to give his/her 100% on
the project he is working on

20
8. Conclusion

Scrum is one of the most widely accepted and used framework across various project in different geography
delivering success. With Scrum, we think differently, collaborate differently and perform differently in achieving the
goal on time.

Scrum is not a magic bullet for all the problems but it is one of the best value based option that has transparency,
periodic review and incremental adaption to deliver the right product for any kind of software projects.

21
Thank You!!!!!!!

22