Agile & Scrum Training

Copyright Conscires 2011
INTRO TO AGILE & SCRUM
Presenter:
Bachan Anand

AGENDA
 SCRUM Framework
 SCRUM Roles

 Planning & Estimation
 Team Engagement
 SCRUM Simulations
 SCRUM Myths
 Class Retrospective

2

AGILE MANIFESTO
 Individuals and interactions over processes and tools
 Working software/product over comprehensive

documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan

3

AGILE 12 PRINCIPLES
 Highest priority is to satisfy the customer
through early and continuous delivery
of valuable software

 Welcome changing requirements
 Deliver working software (Product) frequently
 Business people and developers must work
together daily throughout the project
 Build projects around motivated individuals
 Most efficient and effective method of
conveying information is face-to-face conversation

4

AGILE 12 PRINCIPLES
 Working software (product) is the primary measure of
progress
 Agile processes promote sustainable development

(maintain a constant pace indefinitely)
 Continuous attention to technical excellence
and good design enhances agility
 Simplicity (art of maximizing amount
of work not done) is essential
 Best architectures, requirements, and designs
emerge from self-organizing teams
 At regular intervals, team reflects on how
to become more effective, then tunes and adjusts

http://agilemanifesto.org/principles.html
5

AGILE LEAN ROOTS
 Eliminate Waste – Anything that does not add value
 Build Quality In – Quality if a primary focus

 Deliver fast – Just as it’s defined
 Defer Commitment – Learning before commitment
 Respect People – Give space for others to grow
 Improve the System – The system is the entire process
 Create Knowledge – Sharable and Usable
 Focus on the customer - Needs
 Continuous improvement - Daily
 Kaizen - Change for better processes, led by the people

6

SCRUM FOUNDATION VALUES
 Empiricism
 Detailed up-front planning and defined processes are
replaced by just-in-time Inspect and Adapt cycles

 Self-Organization
 Small teams manage their own workload and organize
themselves around clear goals and constraints
 Prioritization
 Do the next right thing
 Rhythm
 Allows teams to avoid daily noise and focus on
delivery
 Collaboration
 Leaders and customers work with the Team, rather
than directing them 7

SCRUM VALUES
 Transparency
 Everything about a project is visible to everyone
 Commitment

 Be willing to commit to a goal
 Courage
 Have the courage to commit, to act, to be open and to
expect respect
 Focus
 Focus all of your efforts and skills on doing the work
that you have committed to doing
 Respect
 Respect and trust the different people who comprise a
team
8

SCRUM FRAMEWORK

9

SCRUM AND WATERFALL DIFFERENCES
SCRUM Traditional (Waterfall)

Plan what you expect to happen with Plan what you expect to happen
detail appropriate to the horizon

Control happens through inspection Enforce what happens is the same as
and adaption what is planned
•Reviews and Retrospectives •Directive management
•Self-organizing Teams •Control
Use Agile Practices to manage change Use change control to manage change
•Continuous feedback loop •Change Control Board
•Iterative and incremental •Defect Management
development 10
•Prioritized backlogs

SCRUM ROLES DETAILS
 Product Owner
 Maximize the value of the work done by prioritizing
the features by market value

 SCRUM Master
 Manages the SCRUM framework
 Team
 Self-organizing empowered individuals motivated by
business goals
 Other Stakeholders
 Anyone who needs something from the team or the
team something from

11

SCRUM ROLES DETAILS – PRODUCT OWNER
 Thought Leader and Visionary
 Drives the Product Vision (for example, with Story

Mapping)
 Prioritizes the User Stories
 Maintains the Product Backlog with the team
 Accepts the Working Product (on behalf of the customer)

12

SCRUM ROLES DETAILS – SCRUM MASTER
 Servant Leader
 Facilitates the Process

 Supports the Team
 Removes Organizational Impediments
 Socializes Scrum to Management
 Enable close collaboration across all roles and functions

13

SCRUM ROLES DETAILS – SCRUM TEAM
 Cross-Functional
 5-8 Members

 Self-Organizing
 Focused on meeting Commitments

14

ROLES RELATIONSHIP

15

MANAGEMENT ROLES (SERVANT LEADERSHIP)
 Is a servant first and ensures other people – i.e. followers
or stakeholders – highest priority needs are being served

 Empowers others and supports an environment of trust
 Has empathy and sensitivity to the needs and interest of
all stakeholders
 Is open to the voice of others by supporting discussions
that includes those without a voice
 Accept risks; takes the risk of failure along with the
chance of success, while trusting others
 My cup is always full – my focus is now; I’ve learned
from yesterday and I’m planning for tomorrow
16

PRE-SCRUM PLANNING
 Pre-SCRUM is where projects are approved, budgets and
resources assigned
 Project Portfolio’s are expensive

 They are risky
 Do we have the right people with the right experience and
skills?
 Can we afford the project?
 What are the objectives of the project? Clear goals.
 Lack of commitment
 Can we verify the promise was met?
 The business want value and a return on investment
17

PRE-SCRUM PLANNING

Reject

Pre- Active Post-
Portfolio Portfolio Portfolio
Success
or
Failure

Projects Projects Projects
Being formulated Approved Executed
Evaluated Pending Kick-off M & E 18
Pending approval Executing

PRODUCT VISION & ROLE ENGAGEMENT
 A goal to aspire to
 Can be summarized in a short statement of intent

 Communicate it to the team
 Common format:
 For: (Our Target Customer)
 Who: (Statement of need)
 The: (Product/Product name) is a (Product/Product category)
 That: (Product/Product key benefit, compelling reason to buy
and/or use)
 Unlike: (Primary competitive alternative)
 Our Product: (Final statement of primary differentiation)
19

RELATIVE ESTIMATION
 Humans are better at relative estimates than absolute
estimates
 Many heads are better than one

 Estimates are made by those who perform the work
 Estimate size/complexity – Derive duration
 The goal is to get useful estimates with minimal effort
 Estimates are not commitments
 Planning Poker is the common method for estimation

20

RELATIVE ESTIMATION
 Story Points:
 Commonly used in Agile estimation
 No real-world dimensions

 Compare one story to another
 Based on effort, complexity, risk
 Precision is not critical

21

PRODUCT BACKLOG
 A living list of requirements captured in the form of User
Stories
 Represents the WHAT of the system

 Prioritization with respect to business value is essential!
 Each story has estimated Story Points, which represent
relative size, and is determined by those actually doing
the work
 Higher priority items are decomposed and lower priority
items are left as larger stories (epics)

22

USER STORIES
 Product requirements formulated as one or more
sentences in the everyday or business language of the user

 As a <user>, I would like <function> so that I get
<value>
 Each User Story has an associated Acceptance Criteria
that is used to determine if the Story is completed

23

SPRINT BACKLOG
 List of stories, broken down into tasks, that is committed
for any particular Sprint

 Owned and managed by the Team
 Any team member can add, delete or change the sprint
backlog with additional tasks

24

USER STORIES
 Independent
 Not overlap in concept and be able to schedule and
implement them in any order

 Negotiable
 Not an explicit contract for features; rather, details will
be co-created by Product Owner and Team
 Valuable
 Add business value
 Estimated
 Just enough to help the Product Owner rank and
schedule the story's implementation
 Sized Appropriately
 Need to be small, such as a few person-days
25
 Testable
 A characteristic of good requirements

SPRINT PLANNING
 Sprint Planning meeting held at beginning of each Sprint
 Time and Resources are fixed in any given Sprint

 Goal is to have prioritized Sprint Backlog, broken down
into tasks, that the Team can commit to
 During planning, Team commits to scope that can be
completed in the Sprint, taking into account the definition
of Done
 Story points may be refined

26

TASK BOARD
 Active visual indicator of flow
of work
 Should be visible to team

members at all times
 Should be kept current
 Encourages self-organization,
and collaboration

27

DOD - (DEFINITION OF DONE)
 Team creates its own definition of Done in the interest of
creating quality software
 Definition can evolve over sprints

 Example checklist (not exhaustive):
 Unit tests pass (ideally automated)
 Customer Acceptance tests pass
 User docs written
 UI design approved by PO
 Integrated into existing system
 Regression test/s pass (ideally automated)
 Deployed on staging server
 Performance tests pass

28

SPRINT BURN-DOWN
 Shows daily
progress in the
Sprint

 X-axis is the
number of days in
the Sprint
 Y-axis is the
number of
remaining stories

29

RELEASE BURN-DOWN
 Shows progress
across Sprints
 X-axis is the

number of
Sprints
 Y-axis is the total
number of stories

30

DAILY STANDUP MEETINGS
 Meetings held in same location, same time, every day
 Time-boxed at 15 minutes

 Encourages self-organization, rhythm, and collaboration
 Not a status meeting
 Each Team member speaks to:
 What did I accomplish in the last 24 hours
 What do I plan to accomplish in the next 24 hours
 Any impediments getting in the way of my work

31

SPRINT REVIEW
 Occurs at the end of each Sprint
 Inspect and Adapt the product (Empiricism)

 The team meets with the Product Owner (and
Stakeholders) to demonstrate the working software from
the Sprint
 This is a hands-on software demo (not a PowerPoint) that
usually requires some prep beforehand

32

RETROSPECTIVES
 Occurs at the end of each Sprint
 Inspect and Adapt the process (Empiricism)

 Team and ScrumMaster meet to reflect on what went well
and what can be improved
 Tone of the meeting is that everyone did their best and
now look to how can we improve
 Retrospectives must conclude with team commitments to
action

33

SCRUM RELEASE - VELOCITY
 Total number of story points completed by a team in a
Sprint

 Can be used by the team as a reference during Sprint
Planning
 Used by Product Owner to plan out the releases

34

SCRUM RELEASE PLANNING
 Product Owner, in conjunction with the team, formulates
Release Plans by applying the team Velocity to the
Product Backlog

 Release Plans are revisited after every Sprint
 Two ways to approach
 Fix scope and determine how many sprints are needed
 Fix time and determine how much scope can be
completed

35

SCRUM MYTHS
 SCRUM Myths:
 No quality/no testing

 People burnout because of short and frequent delivery
cycles (sprints)
 No culture change is needed
 Will make a better team
 SCRUM is the only Agile method
 Solution to all

36

SCRUM MYTHS
 SCRUM Myths:
 A silver bullet

 Management believes it will solve all problems
 Easy to implement
 Will replace waterfall method
 Cowboy coding
 No documentation
 Simple but not easy

37

SCRUM MYTHS
! SCRUM:
! Exposes issues sooner

! Increases visibility, leading to faster issue resolution
! Facilitates complete feedback & continuous
improvements
! Allows people to fail and learn from failure
! Moves away from the blame culture
! Embraces small incremental changes

38

TAKE AWAY
! Scrum is a lightweight framework with a simple set of
rules, built on foundations and values

! Scrum enables teams to discover their true potential and
deliver quality software that adds business value

39

APPENDIX - ROLES
 Product Owner
 Thought Leader and Visionary, who drives the Product
Vision, maintains the Product Backlog, prioritizes the

User Stories, and accepts the Working Software (on
behalf of the customer)
 ScrumMaster
 Servant Leader, who facilitates the process, supports
the Team, removes organizational impediments, and
socializes Scrum to Management
 Team
 Cross-Functional group of 5-8 Members that is self-
organizing and focused on meeting Commitments
40

APPENDIX – ARTIFACTS
 Product Backlog
 A living list of requirements captured in the form of
User Stories, prioritized according to business value

 Sprint Backlog
 List of stories, broken down into tasks, that is
committed for any particular Sprint; owned and
managed by the Team
 Taskboard
 Active visual indicator of flow of work
 Sprint Burndown Chart
 Shows daily progress in the Sprint
 Release Burndown Chart
 Shows progress across Sprints
41

APPENDIX - CEREMONIES
 Sprint Planning
 Held at beginning of each Sprint, with the goal to have
prioritized Sprint Backlog, broken down into tasks,

that the Team can commit to
 Daily Standup
 Meetings held in same location, same time, every day,
with the goal of ensuring that team members are in
synch (not a status meeting)
 Sprint Review
 Occurs at the end of each Sprint, with the goal of
inspecting and adapting the Product
 Retrospective
 Occurs at the end of each Sprint, with the goal of
inspecting and adapting the process 42

Agile & Scrum Training

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (10)

Ähnlich wie Agile & Scrum Training

Ähnlich wie Agile & Scrum Training (20)

Mehr von Conscires Agile Practices

Mehr von Conscires Agile Practices (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Agile & Scrum Training