This document provides an agenda and overview for an agile workshop. It begins with introductions and an icebreaker for participants. The workshop will cover traditional vs agile approaches, agile principles and practices like Scrum, and requirements. It includes presentations, discussions, and a retrospective. The goal is to educate participants on agile concepts and have them actively engage through the workshop.

1. WELCOME NOTE
&
VISION OF THE WORKSHOP
BY : NAMRATA

2. GETTING TO KNOW EACH OTHER
• YOUR NAME (WITH
ADJECTIVE)
• YOUR ROLE
XXX – Name Title 10 mins

3. 2 mins
Please pick a sticky note, write it and paste it on the
white board.
WHAT DO YOU EXPECT FROM THIS
WORKSHOP?

4. TEAM COMMITMENT TO MAKE THIS SESSION
SUCCESSFUL
Let’s create quick ground rules. I will write it on white
board.

5. WORKSHOP APPROACH
Presentation
Questions
and answersDiscussionsParticipation
by all

6. AGENDA OF THE DAY
SPRINT 1
T1 : TRADITIONAL VS. AGILE
T2 : WHAT IS AGILE?
SPRINT 2
T2 : AGILE PRACTICES
SPRINT 3
T3 : SCRUM
SPRINT 4
T4 : REQUIREMENTS

7. TRADITIONAL APPROACH
Sequential – series of steps
Product Completed after months, if not years
Requirements
Gathered
Architecture
Designed
Coding
Completed
Testing

8. TRADITIONAL PROJECTS VS AGILE
PROJECTS
Stakeholders
Project Manager
SME/BA
Developer
Architect
TesterSME/UAT
Stakeholders
Product Backlog
Scrum Master
Product
Owner

9. WHY AGILE?
 Business is constantly changing, so as our need
 Switch from older to newer technologies in digital era
 People rarely understand requirements from the beginning
 For most middle-to-large systems it is hard (impossible) to
design everything in advance.
 We must respond to our competition
Challenges in Software Development
 No Visibility or delivery for many months
 Fixed Scope Contracts
 No communication or feedback mechanism
 Fail late process and Bad estimation due to lack in clarity
Issues with the traditional approach
9

10. WHAT DO YOU THINK AGILE IS ?

11. Principles
Values
Practices
The Agile Umbrella has three pillars
• Principles: as governed by the Agile Manifesto
• Values: which form the core of the Agile mindset
• Best Practices: to help day to day work

12. AGILE MANIFESTO
OVER (EMPHASIS ON THE
RELATIONSHIP OF SOFTWARE DEVELOPERS THAN INSTITUTIONALIZED PROCESSES
PROCESSES AND TOOLS)
OVER
OVER (RELATIONSHIP IS GIVEN HIGH
PREFERENCE THAN STRICT CONTRACTS.)
OVER (TEAM AUTHORIZED TO ADJUST
CUSTOMER NEEDS DURING SPRINTS)
© 2001, this declaration may be freely copied in any form, but only in its entirety through this notice (source …
www.agilemainfesto.org)
“While there is value in the items on the right,
we value the items on the left more”

13. AGILE PRINCIPLES
Image Courtesy: https://projectmanagers.org/12-agile-principles-free-poster-download/

14. EXECUTION STYLES

15. AGILE PRACTICES
SOME OF THE AGILE METHODS ARE……
o Agile is an umbrella term that
describes several methods
o Each of these methodologies are
implementations of agile
o Each of these has different approach
for implementing the core values of
agile
Agile

16. MOST POPULAR
Source: http://www.versionone.com/pdf/2013-state-of-agile-survey
• Scrum
• Kanban
• Scrumban
• DSDM
• LEAN
• Extreme Programming
(XP)
• Feature Driven
Development

17. Standard Software
Everything is known
Traditional methods
More is known than
unknown
Agile
More is
unknown than
known
Research
Very little is
known
CSC APPROACH
The Spectrum of Process Complexity
Source: Adapted from Ralph D. Stacey, Strategic Management and Organisational Dynamics: The Challenge of Complexity, Prentice Hall, 2000.
WHEN THE PROCESS IS COMPLEX, THE EMPIRICAL APPROACH IS THE
APPROPRIATE CHOICE.”
Scrum
KanBan
XP
Water Fall
Certainty vs Uncertainty

18. AGILE @ ENTERPRISE
SAFe DAD
Scrum of Scrums
LESS
SPOTIFY

19. SCRUM

20. Scrum Ceremonies
 Sprint Planning
 Daily Scrum
 Sprint Demo &
Retrospection
 Product backlog
grooming
Scrum Roles
 The Product
Owner
 The Scrum master
 The Team
Scrum Artifacts
 Product Backlog
 Sprint Backlog
 Burn down Chart
https://www.c-sharpcorner.com/UploadFile/d9c992/the-agile-scrum-
framework/

21. AGILE SOFTWARE DEVELOPMENT
• Empirical And Adaptive.
• Iterative And Incremental.
• Just-enough Planning.
• Just-enough Development.
• Adaptable To Scope Changes.
• Collaborative And Whole-team.
• User Centric.
• Value Driven.
Source: http://en.wikipedia.org/wiki/Agile_software_development

22. Deliver maximum business
value
Eliminate waste
Faster release cycles
Increased quality
Measure and improve
Respond to change
Have Fun
Agile Goals

23. QUICK DEMO
 Traditional Vs. Agile Development
 Agile Values and Principles
 Agile Practices
 Agile at Team Level
 Different Agile frameworks for enterprise
agility
 Scrum is popular
 In nutshell

24. RETROSPECTIVE
• WHAT WENT WELL?
• WHAT DID NOT GO WELL?
• ACTION ITEMS?

25. THEMES, EPICS AND USER-STORIES
• Very high level requirements or vague ideas.
• Detailed enough to initiate programs.
• Implementation spans multiple Sprints.
• Split into themes, epics or user stories.
• Product backlog, portfolio backlog.
• Reasonably vague requirements, some details
known.
• Detailed enough to initiate projects.
• Implementation usually spans sprints
• Split into features or user stories.
• Product backlog, Sprint backlog, portfolio backlogs.
** Feature is another frequently used term
Themes
Epics
As a <role>, I want <ask/desire> so that <benefit>”
• Detailed enough to work in sprint.
• Is able to estimate in story points.
• Add value to the user and is testable.
• Sprint backlog
User Stories

26. 3 C’S IN USER STORY
Card
Conversation
Confirmation
The card captures the general idea. It is a
place to capture the “who”, “what” and
“why” of a user story.
The card provides the basis of a
conversation to develop a shared
understanding of the functionality, goals,
and any constraints.
A well-defined user story can be
completed in one sprint, is testable, and
achieves a clear pass/fail.

27. USER STORY NARRATIVES
Format: “As a <role>, I want <ask/desire> so that
<benefit>”
• Roles are best when
they are from a business
user’s perspective
• Roles speak to how the
software will be used –
provides perspective
• Role can be (not
preferred) a system or
programmer
• Asks are best when
defining a small slice
of business behavior
• Benefits and Roles
are used to scope the
story
• Benefits put a
perspective on the
story’s business use
(value)

28. WHAT MAKES A GOOD STORY?INVEST
Independent
Negotiable
Valuable
Estimable
Small
Testable
Reduced dependencies = easier to plan
Details added by collaboration
Provides value to the customer
Too big or too vague = not estimable
Can be done in one Sprint by the Team
Good acceptance criteria & test scenario
Stories are NOT:
“mini” use cases
a complete
specification
a contract
Intended to be
interpreted without
a Product Owner (or
other proxy)

29. QUICK QUIZ
• “USER STORY” IS A NEW WAY TO WRITE REQUIREMENT – WHY?
• SHOULD WE BE FORCED TO USE THE STORY FORMAT?
• WHAT HAPPENS IF WE DON’T HAVE ALL THE DETAIL WHEN WE START
TO WRITE A STORY?
• WHO WRITES USER STORY?

30. RETROSPECTIVE
• WHAT WENT WELL?
• WHAT DID NOT GO WELL?
• ACTION ITEMS?

31. FEEDBACK