This document provides an introduction to agile principles and Scrum methodology. It defines key Scrum roles like Product Owner and Scrum Master. It also explains common Scrum ceremonies such as sprint planning, daily stand-ups, sprint reviews and retrospectives. Artifacts like the product backlog, sprint backlog and burn down charts are also described. The document aims to give trainees an overview of agile and Scrum concepts to help them apply these principles.
3. Sprint Backlog
TO-DO IN WORK DONE
What is Agile?
Scrum and XP
Usage & risks
3
4. Sprint Backlog
TO-DO IN WORK DONE
What is Agile?
Scrum and XP
Usage & risks
4
5. User Story
As a trainee
I want to understand Agile principles
To be able to apply Agile in various situations
5
6. Agile Manifesto
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
6
7. 12 principles
Our highest priority is to satisfy the customer
Working software is the primary
1 measure of progress. 7 through early and continuous delivery of
valuable software.
Agile processes promote sustainable
Welcome changing requirements, even late in
development. The sponsors, developers,
2 and users should be able to maintain a 8 development. Agile processes harness change
for the customer's competitive advantage.
constant pace indefinitely.
Continuous attention to technical Deliver working software frequently, from a
3 excellence and good design enhances 9 couple of weeks to a couple of months, with a
agility. preference to the shorter timescale.
Simplicity--the art of maximizing the Business people and developers must work
4 amount of work not done--is essential. 10 together daily throughout the project.
The best architectures, requirements, Build projects around motivated individuals.
5 and designs emerge from self-organizing
teams.
11 Give them the environment and support they
need, and trust them to get the job done.
At regular intervals, the team reflects
The most efficient and effective method of
on how to become more effective, then
6 tunes and adjusts its behavior 12 conveying information to and within a
development team is face-to-face conversation.
accordingly.
7
8. Agile - protest movement
• Against:
• waterfall development
• micro management
• disdain for craftsmanship of developers
8
9. Principles no Rules
• YAGNI - you ain’t gonna need it
• BDUF - big design up front
• BPUF - big planning up front
• Simplicity - the art of maximizing the
amount of work NOT done
• Fail fast
9
20. 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
Mountain Goat Software, LLC
21. The ScrumMaster
• 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
Mountain Goat Software, LLC
22. 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
Mountain Goat Software, LLC
24. Release Planning
Product Vision
1 2 3 4 5 6 7 8
User User User User
Story Story Story Story
Epic
User User User User Epic
Story Story Story Story
Epic Epic
User User User User User
Story Story Story Story Story
User User User User User User
Story Story Story Story Story Story
23
25. Release Planning
Product Vision
1 2 3 4 5 6 7 8
User User User User
Story Story Story User stories are the
Story
Epic
Agile way of documenting
User User User User
Story Story Story requirements. Epic
Story
As a <user role> Epic Epic
User User User User User
Story Story Story I want <something>
Story Story
So I can achieve <value>
User User User User User User
Story Story Story Story Story Story
23
26. Sprint planning meeting
Team
capacity
Product
backlog
Business
conditions
Current
product
Technology
24
27. Sprint planning meeting
Team
capacity
Sprint prioritization
Product • Analyze and evaluate product
backlog backlog
• Select sprint goal
Business
conditions
Current
product
Technology
24
28. Sprint planning meeting
Team
capacity
Sprint prioritization
Product • Analyze and evaluate product Sprint
backlog backlog goal
• Select sprint goal
Business
conditions
Current
product
Technology
24
29. Sprint planning meeting
Team
capacity
Sprint prioritization
Product • Analyze and evaluate product Sprint
backlog backlog goal
• Select sprint goal
Business
conditions Sprint planning
• Decide how to achieve sprint
Current goal (design)
product • Create sprint backlog (tasks)
from product backlog items (user
stories / features)
Technology • Estimate sprint backlog in hours
24
30. Sprint planning meeting
Team
capacity
Sprint prioritization
Product • Analyze and evaluate product Sprint
backlog backlog goal
• Select sprint goal
Business
conditions Sprint planning
• Decide how to achieve sprint
goal (design)
Current Sprint
product • Create sprint backlog (tasks)
from product backlog items (user backlog
stories / features)
Technology • Estimate sprint backlog in hours
24
31. Sprint planning
• 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 ScrumMaster
• High-level design is considered
As a vacation Code the middle tier (8 hours)
planner, I want to Code the user interface (4)
Write test fixtures (4)
see photos of the Code the foo class (6)
hotels. Update performance tests (4)
25
32. The daily scrum
• Parameters
• Daily
• 15-minutes
• Stand-up
• Not for problem solving
• Whole world is invited
• Only team members, ScrumMaster, product
owner, can talk
• Helps avoid other unnecessary meetings
26
33. Everyone answers 3 questions
1
What did you do yesterday?
2
What will you do today?
3
Is anything in your way?
• These are not status for the ScrumMaster
• They are commitments in front of peers
27
34. The sprint review
• Team presents what it accomplished during
the sprint
• Typically or underlying architecture of new
features
takes the form of a demo
• Informal
• 2-hour prep time rule
• No slides
• Whole team participates
• Invite the world
28
35. Sprint retrospective
• Periodically take a look at what is and is not
working
• Typically 15–30 minutes
• Done after every sprint
• Whole team participates
• ScrumMaster
• Product owner
• Team
• Possibly customers and others
29
36. Start / Stop / Continue
• Whole team gathers and discusses what they’d like
to:
Start doing
Stop doing
This is just one
of many ways to Continue doing
do a sprint
retrospective.
30
38. Product backlog
•The requirements
•A list of all desired work on the
project
•Ideally expressed the users each
item has value to
such that
or
customers of the product
• Prioritized by the product
owner
This is the • Reprioritized at the start of
each sprint
product backlog
32
39. A sample product backlog
Backlog item Estimate
Allow a guest to make a reservation 3
As a guest, I want to cancel a reservation. 5
As a guest, I want to change the dates of a
3
reservation.
As a hotel employee, I can run RevPAR reports
8
(revenue-per-available-room)
Improve exception handling 8
... 30
Or use T-Shirt
... sizes (S/M/L) 50
33
40. The sprint goal
• A short statement of what the work will be
focused on during the sprint
Life Sciences
Support features necessary for
Database Application population genetics studies.
Make the application run on SQL
Server in addition to Oracle.
Financial services
Support more technical
indicators than company ABC
with real-time, streaming data.
34
41. Managing the sprint backlog
• Individuals sign up for work of their own choosing
• Work is never assigned
• Estimated work remaining is updated daily
• Any team member can add, delete or change the
sprint backlog
• Work for the sprint emerges
• If work is unclear, define a sprint backlog item with a
larger amount of time and break it down later
• Update work remaining as more becomes known
35
42. A sprint backlog
User Story Mon Tue Wed Thu Fri
As a user ... borrow item
... return item
... search for books
... find other books / author
... find book reviews
36
43. A sprint backlog
User Story Mon Tue Wed Thu Fri
As a user ... borrow item 8
... return item 16
... search for books 8
... find other books / author 12
... find book reviews 8
36
44. A sprint backlog
User Story Mon Tue Wed Thu Fri
As a user ... borrow item 8 4
... return item 16 12
... search for books 8 16
... find other books / author 12
... find book reviews 8 8
36
45. A sprint backlog
User Story Mon Tue Wed Thu Fri
As a user ... borrow item 8 4 8
... return item 16 12 10
... search for books 8 16 16
... find other books / author 12
... find book reviews 8 8 8
... read magazines 8
36
46. A sprint backlog
User Story Mon Tue Wed Thu Fri
As a user ... borrow item 8 4 8
... return item 16 12 10 4
... search for books 8 16 16 11
... find other books / author 12
... find book reviews 8 8 8 8
... read magazines 8 4
36
47. A sprint backlog
User Story Mon Tue Wed Thu Fri
As a user ... borrow item 8 4 8
... return item 16 12 10 4
... search for books 8 16 16 11 8
... find other books / author 12
... find book reviews 8 8 8 8 8
... read magazines 8 4
36
57. Definition of Done
From a presentation by Ken Schwaber:
1. I can readily understand the software and where and how things
happen;
2. When I change or add to part of the software, there are no
unintended or poorly designed dependencies;
3. I can read the code without lookin for tricks or poorly defined and
•
labeled variables or is een taak (een stuk code) af?
Wanneer data;
4. I don’t need the person(s) who wrote the code to explain it to me;
5. There are a full set of (automated) tests to check that the function
works as expected;
6. When I change something and add to the test, I can check that the
entire change and product continuous to work;
7. How thing work and hang together is transparent, and
8. Standard, well-known design principles have been adhered to.
39
61. Sprint Backlog
TO-DO IN WORK DONE
What is Agile?
Scrum and XP
Usage & risks
43
62. Sprint Backlog
TO-DO IN WORK DONE
What is Agile?
Scrum and XP
Usage & risks
44
63. Sprint Backlog
TO-DO IN WORK DONE
What is Agile?
Scrum and XP
Usage & risks
45
64. User Story
As a trainee
I want to brainstorm about opportunities and risks
of Agile
Because there’s a trainer around
Because that helps to sink in the ‘slideware’
Because I will also run into these issues when
implementing in my company
46
65. Retrospective
• Workshop
• 3 groups, 2x10 minuten
• “What has made me really thrilled, what
will I start using tomorrow”
• “This is never going to work, because ...”
47
66. Sprint Backlog
TO-DO IN WORK DONE
What is Agile?
Scrum and XP
Usage & risks
48
67. Sprint Backlog
TO-DO IN WORK DONE
What is Agile?
Scrum and XP
Usage & risks
49
68. Credits
• Several slides have been taken from the
Redistributable Scrum Introduction - Scrum
Alliance
50
Editor's Notes
\n
\n
\n
\n
\n
Manifesto brengt spirit in Scrum. Infusion.\n\nProcessen en tools zijn prima, maar we zijn, door teveel focus hierop, wel eens vergeten dat software ontwikkeld wordt door vakmensen, en dat zij echt met elkaar in gesprek moeten gaan.\n\nDocumentatie is belangrijk, maar werkende software nog meer. Bij traditionele milestones werd alleen maar papier opgeleverd.\nOnderzoek naar re-use van software heeft aangetoond dat documentatie over designs maar een heel beperkt nut heeft. Alleen praten met de oorspronkelijke ontwikkelaars over het idee achter het design, en discussie met hen over waar een uitbreiding het beste geplaatst kon worden leidt tot een efficient ontwerp.\nVoorbeeld Wittgenstein - beschrijf een stoel, beschrijf het geluid van een klarinet.\n\nIn contracten met KPI&#x2019;s kan alles dichtgetimmerd worden, waardoor het contract belangrijker wordt dan het tevredenstellen van de klant. Angstcultuur, afrekencultuur zijn het gevolg.\n\nWees realistisch, in vrijwel elk project zal er verandering komen. En dat is goed. Voortschrijdend inzicht van de klant (ik wil eigenlijk iets anders) of van de ontwikkelaars (we weten een slimmere manier) is alleen maar goed. Krampachtig vasthouden aan het oude plan is dan stompzinnig.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Manifesto: working software, customer collaboration, responding to change\n12 Principles:\n- early and continuous delivery\n- changing requirements\n- deliver frequently\n- business and developers work together daily\n- face-to-face communication\n- working software is primary measure of progress\n- self-organising teams\n- regular self-reflection\n
\n
\n
Manifesto: customer collaboration\n12 Principles:\n- business and development work together\n
Impediments\n- risks\n- issues\n- meteen oppakken, niet op een lijstje zetten\n- concreet\nNIET - er is een kans dat we te weinig resources hebben\nWEL - als Judy het grafisch ontwerp niet af krijgt, kunnen we dit item niet leveren\n
Manifesto: working software\n12 Principles:\n- early and continuous delivery\n- deliver frequently\n- business and development work together\n- motivated individuals\n- face-to-face\n- working software\n\n