Training Scrum / Agile held at CWI Software. It contains the principles of agile methods and roles of Scrum.

1. SCRUM
Agile Software Development
Jonas Flesch - me@jonasflesch.com

2. WASTE
Never Rarely Sometimes Frequently Always
Research of the Standish Group in the
largest US project development firms,
revealed that 64% of features requested
by customers are rarely or never used

7. 12 AGILE PRINCIPES

8. 01
Continuous delivery and early software
with value: customer satisfaction

9. 02
Changes are welcome: competitive
advantage for the customer

10. 03
Development in short cycles: frequent
delivery of working software

11. 04
Business people and developers must
work together

12. 05
Motivated individuals, with support and
confidence

13. 06
Face to face conversation is the most
effective method of communication

14. 07
Working software is the best measure of
the project progress

15. 08
Sustainable work pace, no rush and
overtime

16. 09
Technical excellence and good design

17. 10
Simplicity:
The art of maximizing the unrealized
work is essential

18. 11
Self-organized teams:
empowerment!

19. 12
Continuous improvement: inspection and
adaptation

22. SCRUM
• Scrum is based on empirical process
• Defined processes say how they should be executed
• When processes are very complicated to define how, empirical
processes are recommended

23. SCRUM
• Transparency
• Inspection
• Adaptation

25. ROLES:THE SCRUMTEAM

27. PRODUCT OWNER
- Responsible for the backlog and the
value
- Ensures the value of work being done
by the team
- Ensures that the team understands the
items in the backlog

28. SCRUM MASTER
-Teach Scrum and ensures that it is
followed
- Remove impediments
- Eases management of the backlog
- Helps in communication
- Facilitates Scrum events as needed

29. DEVELOPMENT
TEAM
- Auto organized;
- Multi-functional;
- Does not contain sub-teams.

31. SCRUM EVENTS

32. SPRINT
• Scrum heart;
• Fixed time (one month or less);
• No changes affecting the sprint goals
are performed;
• Does not put or remove people from
the team during an Sprint;
• The scope can be renegotiated when
more is learned;

33. PLANNING
• It answers two questions:
• What will be delivered on the next
Sprint?
• How the work to achieve the result
will be done?

34. DAILY SCRUM
• What has been achieved since the last
meeting?
• What will be done until the next
meeting?
• What are the impediments?

35. SPRINT REVIEW
• Inspects the result of Sprint and adapts
the Product Backlog if necessary;
• It is recommended four hours to one
month Sprint;
• The Product Owner finds out what
was done and what was not done;
• The group collaborates on what to do
next;

36. RETROSPECTIVE
• It inspects up as was the Sprint as:
• People
• Relationships
• Processes
• Tools
• It creates a map of gaps and an
improvement plan

37. SCRUM ARTIFACTS

38. PRODUCT BACKLOG
• Ordered: items are sorted according to priority implementation - in
order to maximize customer ROI
• Estimable: judge and form an opinion on the size of the product
backlog or a relevant part of it (eg next Sprint or Release.)

39. PRODUCT BACKLOG
• Emerging: incomplete and dynamic list.The environment evolves
and customers and DevelopmentTeam learn about the product
• Gradually refined: according to the priority
• Top items: smaller granularity, more detail
• Down items: high granularity, minor detail

42. DYNAMIC
Myths and Facts

43. MYTHS AND FACTS: PRODUCT OWNER
1. The PO is the "proxy" or customer representative, conveying their wishes to the Development Team
2. Although it should be influenced by different people, the PO is the only one who can modify the Product Backlog
3. The PO must balance the needs and desires of different stakeholders of the project
4. The best PO's own client or someone chosen by him
5. The PO should be only one person - there should be only a decision point on the product to the Development Team
6. The PO usually can accumulate the role of ScrumMaster smoothly
7. The PO should collaborate closely with the Development Team to maximize the value delivered to the customer
8. The PO should charge the Development Team are committed to all items selected for the Sprint are developed
9. The presence of the PO is not mandatory in the Sprint Planning Meeting - simply the Development Team choose items from
the top of the Product Backlog
10. The PO is responsible for defining the right product to be developed

44. 1. Myth: The PO is the "proxy" or customer representative, conveying their wishes to the Development Team
2. Although it should be influenced by different people, the PO is the only one who can modify the Product Backlog
3. The PO must balance the needs and desires of different stakeholders of the project
4. Myth: The best PO's own client or someone chosen by him
5. The PO should be only one person - there should be only a decision point on the product to the Development Team
6. Myth: The PO usually can accumulate the role of ScrumMaster smoothly
7. The PO should collaborate closely with the Development Team to maximize the value delivered to the customer
8. Myth: The PO should charge the Development Team are committed to all items selected for the Sprint are developed
9. Myth: The presence of the PO is not mandatory in the Sprint Planning Meeting - simply the Development Team choose items from
the top of the Product Backlog
10. The PO is responsible for defining the right product to be developed
MYTHS AND FACTS: PRODUCT OWNER

45. MYTHS AND FACTS: SCRUM MASTER
1. To be effective, the ScrumMaster must have worked as a member of a Development Team
2. The ScrumMaster works for the Scrum be correctly used by teaching and reinforcing the values and rules
3. The ScrumMaster should work to remove impediments to the work of the Development Team, but only those that do not require
organizational changes
4. ScrumMaster is the most important role in a project that uses Scrum
5. The ScrumMaster should have good interpersonal skills to facilitate the resolution of conflicts and promote good communication
6. The ScrumMaster must protect the Development Team from outside interference
7. The ScrumMaster must manage the work of the Development Team
8. The ScrumMaster works toward becoming increasingly necessary
9. ScrumMasters who work all hours in that role better carry out their work
10. In an opinion, impose or interfere with work decisions of the Development Team, the ScrumMaster becomes less efficient as facilitator

46. MYTHS AND FACTS: SCRUM MASTER
1. Myth: To be effective, the ScrumMaster must have worked as a member of a Development Team
2. The ScrumMaster works for the Scrum be correctly used by teaching and reinforcing the values and rules
3. Myth: The ScrumMaster should work to remove impediments to the work of the Development Team, but only those that do not require
organizational changes
4. Myth: ScrumMaster is the most important role in a project that uses Scrum
5. The ScrumMaster should have good interpersonal skills to facilitate the resolution of conflicts and promote good communication
6. The ScrumMaster must protect the Development Team from outside interference
7. Myth: The ScrumMaster must manage the work of the Development Team
8. Myth: The ScrumMaster works toward becoming increasingly necessary
9. ScrumMasters who work all hours in that role better carry out their work
10. In an opinion, impose or interfere with work decisions of the Development Team, the ScrumMaster becomes less efficient as facilitator

47. WHAT A USER STORY ISN'T

48. A MOCKUP

49. USE CASE

50. REMINDER

51. SIMPLETASK
GROUP

52. WHAT IS USER STORY

53. WHO?
WHAT?
WHY?
As an <ROLE>, I can/
should/would
<FUNCTIONALITY> to
<VALUE>
As an buyer, I can SEARCH
BOOKS to CHOOSE ONE
AND BUY

54. ACCEPTANCE CRITERIA
• What will be the format of the alert?
• In which way the alert will be shown?
• Constantly means which frequency?
• How we can know that the order is late?
AN ALERT SHOULD BE CONSTANTLY
SHOWN AS THE SOFTWARE DETECTS
AN LATE ORDER

55. ACCEPTANCE CRITERIA
• Defined the limits of what should be developed for each User
Story;
• The Acceptance Criteria guide the team to avoid adding features
without value in the functionalities, and at the same time, at the
same time ensures the minimum needed to deliver value;
• Are expressed in short and simple phrases;

56. ACCEPTANCE CRITERIA
• The Acceptance Criterias are added to the User Stories in the
refinement sessions of the Backlog;
• Should be written by the Product Owner together with the Team,
to obtain a shared understanding of what must be done;

57. ACCEPTANCE CRITERIA
• The acceptance criteria also guide the team in the definition of
AcceptanceTests;
• Acceptance Criteria are part of the Definition of Done.

59. me@jonasflesch.com
Jonas Flesch