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.
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
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â
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
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
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
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
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?