Agile Scrum Process

2016
Introduction

• Traditional Methodologies
• Agile Methodology
• Scrum
• Scrum Framework: Roles
• Scrum Framework: Ceremonies
• Scrum Framework: Artifacts
• Clarion Scrum Process-Review
Traditional Methodologies: Waterfall Model

• You complete one phase (e.g. design)

before moving on to the next
phase(e.g. development)
• You rarely aim to re-visit a ‘phase’ once
it’s completed. That means, you better
get whatever you’re doing right the first
time!
Traditional Methodologies: Waterfall Model
Changes

• You don’t realize any value until the end

of the project
• You leave the testing until the end
• You don’t seek approval from the
stakeholders until late in the day Takes too long Skipped

• Takes too long…

**This approach is highly risky, often

more costly and generally less efficient
than Agile approaches
Agile Meaning (Literally)
Ability to move quickly and easily….
Agile Methodology

Not a process, it's a philosophy or set of values…

Rapid Adaptive Agile Quality-Driven Cooperative Iterative

Agile Manifesto

Individuals and interactions Process and tools

Working software O Comprehensive documentation

V
E
R
Customer collaboration Contract negotiation

Responding to change Following a plan

12 Agile Principles

• Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.

1 ROI
12 Agile Principles

• Welcome changing requirements, even late in development. Agile processes

harness change for the customer's competitive advantage.

2 CHANGEABILITY
12 Agile Principles

• Deliver working software frequently, from a couple of weeks to a couple of

months, with a preference to the shorter timescale.

3 GETTING REAL
12 Agile Principles

• Business people and developers must work together daily throughout the
project.

4 ALIGNMENT
12 Agile Principles

• Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.

5 SELF
ORGANIZATION
12 Agile Principles

• The most efficient and effective method of conveying information to and within
a development team is face-to-face conversation.

6 BANDWIDTH
12 Agile Principles

• Working software is the primary measure of progress.

7 DONE
12 Agile Principles

• Agile processes promote sustainable development. The sponsors, developers,

and users should be able to maintain a constant pace indefinitely.

8 SUSTAINABILITY
12 Agile Principles

• Continuous attention to technical excellence and good design enhances agility.

9 IMPROVEMENT
12 Agile Principles

• Simplicity —the art of maximizing the amount of work not done —is essential.

10 KEEP IT SIMPLE,
STUPID (KISS)
12 Agile Principles

• The best architectures, requirements, and designs emerge from self-organizing

teams.

11 EMERGE
12 Agile Principles

• At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.

12 INSPECT & ADOPT

Various Agile Methodologies
Meaning Of Scrum (Literally)
What Is Scrum?

• Scrum is an agile framework that allows us to focus on delivering the highest

business value in the shortest time.
• It allows us to rapidly and repeatedly inspect actual working software (every two
weeks to one month).
• The business sets the priorities. Teams self-organize to determine the best way
to deliver the highest priority features.
• Every two weeks to a month anyone can see real working software and decide
to release it as is or continue to enhance it for another sprint.
Scrum Origins

Some professionals believe Others, who vouch for

that Jeff Sutherland, John HirotakaTakeuchi and
Scumniotales and Jeff IkujiroNonakaas inventing
McKenna invented Scrum Scrum in 1986.
in 1993.

Controversies
Who Is Using Scrum?

Electronic Arts Lexis Nexis Microsoft

Google Lockheed Martin Nielsen Media
Ipswitching Sabre BBC Siemens Capital
BMC Software Turner Broadcasting One

First American Real Estate Yahoo

John Deere Time Warner Amazon
Salesforce.com High Moon Studios
Clarion Technologies
Where To Use Scrum?

• Commercial software • Video game development

• In-house development • FDA-approved, life-critical
• Contract development systems

• Fixed-price projects • Satellite-control software

• Financial applications • Websites

• ISO 9001-certified applications • Handheld software

• Embedded systems • Mobile phones

• 24x7 systems with 99.999% uptime • Network switching applications

requirements • ISV applications
• The Joint Strike Fighter • Some of the largest applications
in use
Scrum Framework

Roles

• Product owner
• Scrum Master
• Team

Ceremonies

• Sprint planning
• Sprint review
• Sprint retrospective
• Daily scrum meeting

Artifacts

• Product backlog
• Sprint backlog
• Burndown charts
Scrum Framework

Roles

• Product owner
• Scrum Master
• Team

Ceremonies

• Sprint planning
• Sprint review
• Sprint retrospective
• Daily scrum meeting

Artifacts

• Product backlog
• Sprint backlog
• Burndown charts
Role: Product Owner

• Define the features of the product

• Decide on release date and content
• Be responsible for the profitability of the product (ROI)
• Prioritize features according to market value
• Adjust features and priority every iteration, as needed
• Accept or reject work results
Role: Scrum Master

• Represents management to the project

• Responsible for enacting Scrum values and practices
• Removes impediments
• Ensure that the team is fully functional and productive
• Enable close cooperation across all roles and functions
• Shield the team from external interferences
Role: The Team

• Typically 5-9 people

• Cross-functional
• Programmers, testers, user experience designers, etc.
• Members should be full-time
• May be exceptions (e.g., database administrator)
• Teams are self-organizing
• Ideally, no titles but rarely a possibility
• Membership should change only between sprints.
Clarion Role Mapping

Product owner/ Product owner is generally from client side and

shadow product owner would be from BA/SA
Shadow product owner
PO BA
offshore side. In some cases product owner could
be from offshore, who has gained detailed
product/system knowledge, this scenario does not
require shadow P.O.

Team facilitator from offshore side to drive overall

Scrum master scrum process
Scrum Master

Cross functional scrum Technical Architect (onsite + offshore), Technical

Leader, QA, Developers and Designers.
team
Cross-functional
scrum team
Scrum Framework

Roles

• Product owner
• Scrum Master
• Team

Ceremonies

• Sprint planning
• Sprint review
• Sprint retrospective
• Daily scrum meeting

Artifacts

• Product backlog
• Sprint backlog
• Burndown charts
Ceremony: Sprint Planning Meeting

• Team selects items from the product backlog they can commit to completing
• Sprint backlog is created
• Tasks are identified and each is estimated (1-16 hours)
• Collaboratively, not done alone by the Scrum Master
• High-level design is considered
Clarion: Sprint Planning Meeting

• Purpose: At every sprint start, sprint backlog is created out of product backlog.
• Participants: Product owner, scrum master, team
• Duration: This is a time-boxed meeting, duration depends on the duration of
sprint and complexity of the items.
• Highlights:
• Fibonacci point based estimates which would be related to the complexity / time of
the tasks.
• Stories are discussed in sprint planning meeting and estimation will be given by
developers on based of story, planning poker is used for the user story
estimation.
• Generally for 1 point we consider 2-3 hours work, 2 pointer it is a half day work, 3
pointer is a days work and 5 pointer is 2 days work.
Planning Poker
... …… …..

• Product Owner reads story

• Team estimates (including QA/Testing) PO 1
• Team Discusses
• Team estimates again
5

This process is repeated till consensus

is reached.
Clarion Pre-sprint Planning Meeting

• Happens a day before actual Sprint planning meeting.

• All the internal team members participate.
• Few the tentative stories are picked from the prioritized product backlog.
• Team discuss and understands the stories and the underlying challenges and
questions in the upcoming stories.
• For the new team it is suggested to do the point estimation also during pre-
sprint planning.
• The purpose is to facilitate the main Sprint planning with client.
Ceremony: Daily Standup

• Parameters
• Daily
• 15-minutes
• Stand-up
• Not for problem solving
• Whole world is invited
• Only team members, Scrum Master, Product Owner, can talk
• Helps avoid other unnecessary meetings
Clarion DSM
Yesterday I did…
Today I plan to…
Purpose: I am facing some impediments...

• Each team member summarizes

• What was done yesterday
• What would be done today
• If there are any Issues being faced.
• This helps coordinating priorities of the Cross-functional
scrum team
day.
PO BA
Scrum Master
• Participants: Product owner, scrum
master, team
• Duration: Short duration of around 15
minutes.
Ceremony: Sprint Review

• Team presents what it accomplished during the sprint

• Typically takes the form of a demo of new features or underlying architecture
• Informal
• 2-hour prep time rule
• No slides
• Whole team participates
• Invite the world
Ceremony: Sprint Review I declare that following product
backlog items as “Done”
1.…
2.…
Based on feedback we need to
• Purpose: At the sprint execution end, sprint add some new product backlog
items.
review meeting would be held for following
• Shippable product would be demoed to the PO BA
Product Owner (PO) in this meeting.
• Product Owner (PO) can accept or reject the
Scrum Backlog items presented in the demo.
• There could be new product backlog items
identified during this meeting
Cross-functional
scrum team

• Participants: Product owner, scrum master, Scrum Master

team, interested stakeholders

• Duration: In general this meeting should not
be longer than one hour per week of sprint
Stakeholders
(optional)
duration.
Ceremony: Sprint Retrospective

• Periodically take a look at what is and is not working

• Typically 15–30 minutes
• Done after every sprint
• Whole team participates
• Scrum Master
• Product owner
• Team
• Possibly customers and others
Clarion Sprint Retrospective Meeting

• Purpose: This meeting is held at the end of ... …… …..

each sprint (after the sprint review), it
facilitates team to inspect and adapt its ... …… …..
process to optimize efficiency. ... …… …..
• In this meeting following points would be
discussed.
• What went well in the sprint. Cross-functional
• What did not went well in the sprint. scrum team

• How can we enhance.

• The output of this meeting becomes the input PO BA

for next sprint for enhancing the practice. Scrum Master

• Participants: Product owner, scrum master,

team
• Duration: In general this meeting should not
be longer than 45 minutes for each week of
sprint duration.
Add On’s: Clarion Product Backlog Grooming meeting

• Purpose: This is done couple of work

Requirement Requirement
Requirement Requirement
Sprint Planned Sprintable
days before next sprint planning meeting, Requirement
Requirement
Requirement
Requirement

which give product owner little time to Requirement

Actionable/ User Stories
revise priorities before commitments are
Requirement
Groomed Requirement

made. Team focuses on top few items

Requirement

Epic / Cosmic Stories

only, this helps the team to clarify &
Future Requirement Requirement

decompose the higher priority PBIs

• Participants: Product owner, scrum PO BA

Scrum Master
master
Cross-functional
• Duration: In general this meeting should scrum team

not be longer than 2 hours.

Scrum Framework

Roles

• Product owner
• Scrum Master
• Team

Ceremonies

• Sprint planning
• Sprint review
• Sprint retrospective
• Daily scrum meeting

Artifacts

• Product backlog
• Sprint backlog
• Burndown charts
Artifact: Product Backlog

• The requirements
• A list of all desired work on the project
• Ideally expressed such that each item has value to the users or customers of
the product
• Prioritized by the product owner
• Reprioritized before the start of each sprint
Clarion Product Backlog

• It is prioritized list of user stories

covering whole product/system.
PO BA

• Before the sprint planning meeting Scrum Master

product Backlog items will be created by Cross-functional

Product Owner(PO) in collaboration with scrum team

Business Analyst(BA) from offshore side, WORK ITEM 1

who would act as a shadow product High Priority Items

owner.
WORK ITEM 2

WORK ITEM 3
• Stories defined should follow INVEST
principle of Scrum. WORK ITEM 4

• Break down Epics. WORK ITEM 5

WORK ITEM 6
User Story

A concise, written description of a piece of functionality that will be

valuable to a user (or owner) of the software.

A user story should be detailed enough for the team to start work from,
and further details can be established and clarified at the time of
development.
3C’s Of User Story

• Card - A written description of the user story for planning purposes and as a
reminder.
• Conversation - A section for capturing further information about the user story
and details of any conversations.
• Confirmation - A section to convey what tests will be carried out to confirm the
user story is complete and working as expected.
User Story: Invest In It

• Independent - User Stories should be as independent as possible.

• Negotiable - User Stories are not a contract. They are not detailed
specifications. They are reminders of features for the team to discuss and
collaborate to clarify the details near the time of development.
• Valuable - User Stories should be valuable to the user (or owner) of the
solution. They should be written in user language. They should be features, not
tasks.
• Estimable - User Stories need to be possible to estimate. They need to provide
enough information to estimate, without being too detailed.
• Small - User Stories should be small. Not too small. But not too big.
• Testable - User Stories need to be worded in a way that is testable, i.e. not too
subjective and to provide clear details of how the User Story will be tested.
User Story: Format

As a [role] I want to [a feature] so that [reason, value].

As a frequent traveler I want to be able to quickly rebook frequently booked

flights so that I can save time during the booking process.
User Story: Example

• Epic#1: User Authentication and Authorization Module

• Story#1: Registration System for school user

• Description: As a visitor of the site, I want to be able to register by providing my
email and password in order to use the available features.
• Acceptance Criteria:
• I should be presented with a link on top right corner to register titled ‘Register’.
• I should be presented with a form asking email, password, password confirmation.
• I should be presented with a Register button, clicking on which I should be
registered as a user on app.
• I should be presented with errors in case of incorrect email format and a password
shorter than 8 chars.
Artifact: Sprint Backlog

• The sprint backlog is a list of tasks identified by the Scrum team to be

completed during the Scrum “Sprint”.
• During the sprint planning meeting, the team selects some number of product
backlog items
What Is Sprint?

A sprint is a set period of time during which specific work has to be

completed and made ready for review.
More precisely we can say a Sprint is a Time Box.

• During the actual sprint, team implements the user stories committed to the
sprint backlog in continuous integration mode.
• Duration: Usually from 2 weeks to 4 weeks.
Clarion Sprint Cycle
Design &
Analysis

Detailed Implementation
requirements & unit testing

Continuous
Deployment
Integration

Testing & QA

Every sprint consists of iteration of following tasks

Actual Sprint - Starting Mid-week

• Advantages & probable scenarios when this cycle would be suggested

• This way even if we have to stretch a bit to finish some tasks, team would not
hesitate to do it during mid-week.
• In addition to this if teams are working in distributed agile set-up, then mid-week
start helps the product owner to be easily available.
• This cycle is suitable when the releases can be done on weekdays.

2 WEEK SPRINT STARTING MID WEEK (10 WORKING DAYS)

TUE WED THU FRI MON TUE WED THU FRI MON
-----------
-----------------------------------------------------------------------------------------------------
---------------------------------------------
-----------
Sprint Daily standup meeting Product backlog grooming Sprint review /
planning retrospective
meeting
Actual Sprint - Starting On Monday

• Advantages & probable scenarios when this cycle would be suggested

• This cycle is suitable when the releases can only be done on weekends.

2 WEEK SPRINT STARTING MID WEEK (10 WORKING DAYS)

MON TUE WED THU FRI MON TUE WED THU FRI
-----------
-----------------------------------------------------------------------------------------------------
---------------------------------------------
-----------
Sprint Daily standup meeting Product backlog grooming Sprint review /
planning retrospective
meeting
Sprint Zero

• Purpose: This is carried out to initiate

the overall scrum process and the
logistics related to the project.
• Participants: all the team participates
in this sprint and it is driven by scrum PO BA
Scrum Master
master.
Cross-functional
• Duration: Approximately 2 weeks scrum team

Sprint Zero High Level Tasks

• Initial grooming of the product catalog.
• Decide maximum base point for user story.
• Decide the sprint duration and sprint release cycle.
• Technical understanding by team.
• How and where QA would be done.
• Setting up environments.
Artifact: Burn-down Chart

• Tells us about: 300

• How much work is remaining to be 250

done in the project 200

• How much deviation we are having

150

100
from the current estimation or are we 50
pulling in lot of tasks in the sprint 0

Sample burn down and inferences

Ideal Team Great Team Nice Team Too Fast Too Late
Add On’s: Burn-up Chart

• Tells us about:
BURN UP TASK

60

• How much work has been completed, 50

and the total amount of work. 40

No. of tickets
• How the sprint is progressing with 30

reference to change in scope. 20

10

0
11/4 12/4 13/4 16/4 17/4 18/4 19/4 20/4 23/4 24/4

Total April
Add On’s: Velocity Chart

• Shows the amount of value delivered in

VELOCITY CHART

60

each sprint, enabling you to predict the 50

amount of work the team can get done 40

Story Points
30
in future sprints. 20

• It is useful during your sprint planning

10

meetings, to help you decide how much

Sprint 1 Sprint 2 Sprint 3 Sprint 4
Commitment 40 53 56 57

work you can feasibly commit to.

Completed 37 47 50 57

Commitment Completed

• Initial velocity figures could below,

however a steam moves forward we get
the better idea about the capability of
the team.
Clarion Scrum Process - An Overview
Clarion Scrum Process
PRODUCT BACKLOG SPRINT BACKLOG
WORK ITEM 1 TASK TASK TASK

WORK ITEM 1
PRODUCT TASK TASK
WORK ITEM 2 INCREMENT

WORK ITEM 3 TASK TASK TASK

WORK ITEM 2 Product

Backlog
TASK TASK TASK
WORK ITEM 4

WORK ITEM 5
WORK ITEM 3
TASK TASK PO BA Grooming Information Radiator
Online Scrum Tool
TASK TASK
WORK ITEM 6

Scrum
Master

Daily Sprint Sprint

Sprint Sprint Planning
Scrum Review Retrospective
Zero Meeting
Meeting Meeting Meeting

Design Code

Sprint
Analysis CI
Preplanning
Cross-functional
scrum team Deploy Test
Online Scrum Management Tools

• There are many project management tools available with scrum support for
example
• Redmine - http://www.redmine.org/
• Assembla - https://www.assembla.com/home

• Based on our past experience we suggest JIRA for Scrum process management
• JIRA tool will be used as the online Scrum management tool and will act as the
information radiator.
• Standup
• Git/SVN Repository
• Continuous Integration

More details are on https://www.atlassian.com/software/jira/agile

Thank You!