Agenda

Traditional Software Development

What’s Agile?

SCRUM Framework

Team & Roles

Ceremonies

Artifacts

Requirements

ALL RIGHTS RESERVED 2016 - SENSIPLE 1 VISIONEERING.THE CHANGE

Traditional Methods of Software Development

Classical methods of software development have many disadvantages:

 Huge effort during the planning phase
Direct Impact
 Poor requirements conversion in a rapid changing environment – better
get whatever u are doing right the first time
 Difficulty with incomplete or changing requirements
 Treatment of staff as a factor of production
 No working software is produced until late during the life cycle
 Time to discover problems is too long

ALL RIGHTS RESERVED 2016 - SENSIPLE 2 VISIONEERING.THE CHANGE

CHALLENGES TODAY

Evolving and
Lack of Clarity on Short Time to
Changing
Requirements Market
Requirements

Innovation Market & Trends

ALL RIGHTS RESERVED 2016 - SENSIPLE 3 VISIONEERING.THE CHANGE

What’s Agile?

Not a Process!

It’s a philosophy
or a set of values!

ALL RIGHTS RESERVED 2016 - SENSIPLE 4 VISIONEERING.THE CHANGE

Why Agile?

ALL RIGHTS RESERVED 2016 - SENSIPLE 5 VISIONEERING.THE CHANGE

Why Agile?

Time to Market
• Early and Regular Releases

Revenue
• Early ROI

High Quality & Productivity

• Testing is integrated throughout the cycle

Risk Mitigation by short deliverables

• Multiple opportunities to recover from missteps

Business Engagement/Customer Satisfaction

• Continuous demo and feedback from customer

Motivated Teams
• Increased involvement and participation from team

ALL RIGHTS RESERVED 2016 - SENSIPLE 6 VISIONEERING.THE CHANGE

Different Agile Methodologies

OUR FOCUS

SCRUM

ALL RIGHTS RESERVED 2016 - SENSIPLE 7 VISIONEERING.THE CHANGE

SCRUM

ALL RIGHTS RESERVED 2016 - SENSIPLE 8 VISIONEERING.THE CHANGE

SCRUM

Agile process that allows us to focus on delivering the highest business value in the
shortest time.

Self Organizing Teams that are cross functional

Requirements are captured as items in a list of “product backlog”

Business sets priorities and teams deliver based on high priorities

One sprint is planned at a time and they are time boxed

Every sprint produces a potentially shippable increment

Definition of Done is met in every sprint

ALL RIGHTS RESERVED 2016 - SENSIPLE 9 VISIONEERING.THE CHANGE

SPRINT

 Heart of Scrum
 Scrum projects make progress in a series of “sprints”
 Recommended Duration - two to four weeks
 Duration of sprint remains consistent across the project
 Goal is to have an iteration short enough to keep the team focused but long enough to deliver a
meaningful increment of work
 Product is designed, coded, and tested during the sprint
 No changes are taken up during the sprint
 Plan sprint durations around how long you can commit to keeping change out of the sprint

Change

Inputs Sprint Tested Code

ALL RIGHTS RESERVED 2016 - SENSIPLE 10 VISIONEERING.THE CHANGE

SCRUM FRAMEWORK
Roles

Artifacts
Ceremonies

Product Owner Sprint Planning Product Backlog

Scrum Master Sprint Review Sprint Backlog
Team Sprint Retrospective Potentially Shippable
Daily Scrum Meeting Increment
Product Backlog Grooming

ALL RIGHTS RESERVED 2016 - SENSIPLE 11 VISIONEERING.THE CHANGE

Team

TEAM – ROLES

ALL RIGHTS RESERVED 2016 - SENSIPLE 12 VISIONEERING.THE CHANGE

Team

Waterfall SCRUM

ALL RIGHTS RESERVED 2016 - SENSIPLE 13 VISIONEERING.THE CHANGE

ROLES

Product Owner
 Define the features of the
product
 Decides on release date and
content
 Prioritize features according to
market value Who can be PO
 Adjust features and priority  Customer
every iteration, as needed
 Product Managers
 Accept or reject work results.
 Program Managers
 Maintains the Product Backlog
 Business Analysts
 Any Key Stakeholder

ALL RIGHTS RESERVED 2016 - SENSIPLE 14 VISIONEERING.THE CHANGE

ROLES

The Scrum Master

 Represents management to the
project
 Responsible for enacting Scrum
values and practices - Coach
 Removes impediments
 Ensure that the team is fully
Who can be SM
functional and productive
 Enable close cooperation across  Experienced Team
all roles and functions and Member
resolves conflicts  Ex-Product Managers
 Shield the team from external –
interferences
 Reporting, Communication,
Feedback

ALL RIGHTS RESERVED 2016 - SENSIPLE 15 VISIONEERING.THE CHANGE

ROLES

Scrum Team
 Typically 5-9 people
 Cross-functional
 Members should be full-time
 May be exceptions (e.g.,
System Admin, etc.)
Who can be part of SCRUM Team?
 Teams are self-organizing
 Architects
 Responsible for work done
 Developers
 Testers
 Business Analysts
 UI Designers
 Document Writers

ALL RIGHTS RESERVED 2016 - SENSIPLE 16 VISIONEERING.THE CHANGE

CEREMONIES

CEREMONIES

ALL RIGHTS RESERVED 2016 - SENSIPLE 17 VISIONEERING.THE CHANGE

Sprint Planning

Product Backlog

Team Capabilities
Sprint Goal
Sprint Planning
Business Conditions
Meeting Sprint Backlog
Technology

Current Product

ALL RIGHTS RESERVED 2016 - SENSIPLE 18 VISIONEERING.THE CHANGE

Sprint Planning

Sprint Planning

• Creating Sprint Backlog

• Determining the Sprint Goal
• Participants: Product Owner, Scrum Master,
Scrum Team
• Conducted and Time boxed by Scrum Master
• Dev team arrives at list of tasks for chosen
stories and commits to tasks
• Assign effort (hours) against tasks
• Half a day in a 2 week sprint

ALL RIGHTS RESERVED 2016 - SENSIPLE 19 VISIONEERING.THE CHANGE

Daily Scrum Meeting

Daily Scrum Meeting

• Parameters
Daily
15-minutes
Stand-up
Not for problem solving
• Three questions:
What did you do yesterday
What will you do today?
What obstacles are in your way?
Everybody listens and there is no discussion
• Conducted by SCRUM master with scrum team

ALL RIGHTS RESERVED 2016 - SENSIPLE 20 VISIONEERING.THE CHANGE

Product Backlog Grooming

Product Backlog Grooming

• Conducted in every sprint

• Looking at upcoming 2-3 sprints worth of Product
backlog items (sprinting ahead)
• Scrum team tries to get a detailed understanding
of these items through interactions with PO
• Product Backlog could revisited/reprioritized
based on inputs from PO in consultation with
Scrum team
• Provide Story Points estimates for stories
• 5-10% of time in a sprint

ALL RIGHTS RESERVED 2016 - SENSIPLE 21 VISIONEERING.THE CHANGE

Sprint Review Meeting

Sprint Review Meeting

• Conducted at end of sprint by PO and stakeholders

• Inspection of quality of what is produced by team
• Check “Done-ness” of items produced and suggest
improvements
• Team presents what it accomplished during the sprint
• Participants
• Customers
• Management
• Scrum Team

ALL RIGHTS RESERVED 2016 - SENSIPLE 22 VISIONEERING.THE CHANGE

Sprint Retrospective Meeting

Sprint Retrospective Meeting

• Inspect and adapt the process

• Share experiences and observations during the
sprint
• Three questions
• what to start doing
• stop doing
• what to continue from next sprint
• Plan for improvements in future sprints
• An important practice in each sprint

ALL RIGHTS RESERVED 2016 - SENSIPLE 23 VISIONEERING.THE CHANGE

CEREMONIES

ARTIFACTS

ALL RIGHTS RESERVED 2016 - SENSIPLE 24 VISIONEERING.THE CHANGE

Product Backlog

PRODUCT BACKLOG
Owned by Product Owner
List of items to be developed
Prioritized by Product Owner based on inputs from stakeholders
Items are written in form of User Stories - Usually a combination of Story based
work and task based work

ALL RIGHTS RESERVED 2016 - SENSIPLE 25 VISIONEERING.THE CHANGE

Sprint Backlog

SPRINT BACKLOG
Owned by Scrum Team
A subset of Product Backlog Items, which define the work for a Sprint
List of tasks with effort estimations for the stories chosen for the current sprint
Decided by Scrum Team with inputs/clarifications from Product Owner
Decided during Sprint Planning Meeting
Team self-organizes around how they’ll meet the Sprint. They are not assigned by
Manager.

ALL RIGHTS RESERVED 2016 - SENSIPLE 26 VISIONEERING.THE CHANGE

Potentially Shippable Increment

Potentially Shippable Increment

Owned by Scrum Team
Working version of development at end of sprint
Reviewed by Product Owner and Key Stakeholders at the end of sprint
Can be wireframes, skeleton code proving the design, module that can be
deployed etc

ALL RIGHTS RESERVED 2016 - SENSIPLE 27 VISIONEERING.THE CHANGE

CEREMONIES

Requirements

ALL RIGHTS RESERVED 2016 - SENSIPLE 28 VISIONEERING.THE CHANGE

Our focus - Requirements

ALL RIGHTS RESERVED 2016 - SENSIPLE 29 VISIONEERING.THE CHANGE

Our focus - Requirements

ALL RIGHTS RESERVED 2016 - SENSIPLE 30 VISIONEERING.THE CHANGE

Our focus - Requirements

ALL RIGHTS RESERVED 2016 - SENSIPLE 31 VISIONEERING.THE CHANGE

Our focus - Requirements

ALL RIGHTS RESERVED 2016 - SENSIPLE 32 VISIONEERING.THE CHANGE

User Stories

A concise, written description of a piece of functionality that will be valuable to a user (or owner) of
the software.

1. Who (user role)

2. What (task)

3. Why (reason/goal)
gives clarity as to why a feature is useful, can influence how
a feature should function, can give you ideas for other
useful features that support the user's goals

1. Card - A written description of the user story for planning purposes and
as a reminder

2. Conversation - A section for capturing further information about the user

story and details of any conversations

3. Confirmation - A section to convey what tests will be carried out to

confirm the user story is complete and working as expected – Defining
Acceptance Criteria

ALL RIGHTS RESERVED 2016 - SENSIPLE 33 VISIONEERING.THE CHANGE

User Stories

 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.

ALL RIGHTS RESERVED 2016 - SENSIPLE 34 VISIONEERING.THE CHANGE

Metrics

Burn Down Chart

Velocityis a measurement of how much the team gets done in an iteration ( called as
Sprint in Scrum ). Velocity is what actually got done in the last iteration not what is
planned. In Scrum it is measure in Story points.

ALL RIGHTS RESERVED 2016 - SENSIPLE 35 VISIONEERING.THE CHANGE

Tools

 JIRA
 RALLY
 ACTIVECOLLAB
 AGILO
 VERSIONONE
 SPRINTGROUND

ALL RIGHTS RESERVED 2016 - SENSIPLE 36 VISIONEERING.THE CHANGE

Barriers to Agile Adoption

ALL RIGHTS RESERVED 2016 - SENSIPLE 37 VISIONEERING.THE CHANGE

ALL RIGHTS RESERVED 2016 - SENSIPLE 38 VISIONEERING.THE CHANGE