A brief introduction to Agile and Scrum

1. Introduction to Agile &
Scrum Workshop

2. Introduction
• Course Overview
• Content
• Learning Outcomes

3. Who is here today?
• Name
• Current role
• Who is your favourite artist of all time?
• Expectations from this workshop

4. Today…
• Learn about Agile & Scrum
• Lots of group exercises
• Please ask questions
• Have fun!

5. What we will cover
• Agile
• Scrum
• User Stories
• Agile Estimation
• Backlog Management
• Continuous Development

6. Learning Outcomes
At the end of today you will be able to:
• Describe agile, and how it differs from Scrum.
• Describe the basic rules of Scrum.
• Write and Evaluate User Stories.
• Describe Relative and Absolute Estimation
• Describe Story Points
• Play Planning Poker
• Play Fast Estimation
• Prioritise a Backlog, while considering Value and Risk.
• ...

7. Learning Outcomes (cont’d)
At the end of today you will also be able to:
• Describe how Sequential and Continuous Development differ.
• List some of the practices that are used in Continuous Development.
• Describe Technical Debt and list some elements of managing debt.

8. Agile

9. Introduction to Agile
• Why Agile?
• Agile Manifesto
• Domination of Scrum

10. Would you trust this man?

11. You Should!
• In the early 90’s
• Most software projects were failing
• But they were all succeeding
• What was different?
• ‘agile’

12. Very brief history of agile & Scrum
70 ‘s
Waterfall
created
Scrum
createdRate of Business Change
Accelerates
2013199390’s
Scrum
Dominate
Light weight
Methodologies
arise
2001
agile
Manifesto
created
The New New
Product
Development
Game
1986

13. Source: http://www.versionone.com/Agile101/Agile-Software-Development-Benefits/
How to Sell Agile to your Boss?

14. Exercise - Presto Manifesto
1. Define a successful project?
2. Form teams.
3. List of ‘critical elements of successful projects’.
4. Reach team consensus & signs those that they agree with.
5. Review similarities between teams.
6. Review similarities to the agile manifesto.

15. Agile manifesto (just value statement)
Process and tools
Individuals and
interactions
over
Following a planResponding to change over
Comprehensive
documentation
Working software over
Contract negotiationCustomer collaboration over
Full Manifesto: http://agilemanifesto.org/

16. Why is Agile Hard?
• Values & Principles
• New practices
• Best learnt by doing
• Requires time to master

17. Domination of Scrum
0%
10%
20%
30%
40%
50%
60% DSDM
Agile Modeling
Agile Unified
Process
Other
Lean
FDD
XP
Don't Know
Kanban
Scrumban
Custom Hybrid
Scrum / XP Hybrid
Scrum
Source: Version One – 7th Annual State of Agile Survey

18. Domination of Scrum
Scrum variants
Other
Source: Version One – 7th Annual State of Agile Survey

19. Scrum

20. Introduction to Scrum
• Why use Scrum?
• Scrum Frameworks
• Variations
• Success

21. Why use Scrum?
• Adheres to agile manifesto
• Find the fun earlier
• Faster feedback
• Reduce crunch periods

22. Scrum Roles
Person Scrum Master Product Owner Team Member
A Yes No Yes
B No Yes No

23. Responsibilities in Scrum
Scrum Master Product Owner Team Member
Adherence to rules Return on Investment Deliver
Whole team effectiveness What, Why How

24. Scrum Artefacts
• Product Backlog
• Sprint Backlog
• Shippable Software Increment

25. Scrum Ceremonies
• Backlog Refinement/Grooming
• Sprint Planning
• Daily Standup
• Sprint Review
• Spring Retrospective

26. Values: Focus, Courage, Openness, Commitment, Respect

27. Definition of Done
• Defines what gets to ‘Done’
• Used to ensure Quality
• Used to reduce debt
• Created by whole team
• Can be updated
• Automated Tests passing
• Code Reviewed
• Product Owner accepted
• Checked into mainline
• Tracking tool updated
• Deployed to Intg. Env.
e.g.

28. Sprint Commitments
• Product Owner: Won’t change the Sprint Backlog.
• Team: Deliver the Sprint Backlog.
• Scrum Master: Protect the team from outside influences.
Keep in mind we will learn through the sprint, and we
should deliver the most value that we can.

29. Exercise – match activities by role
• Divide the large paper into three equal sections: Team, SM, PO.
• Match up the activity cards to the section.
• NOTE: Some cards are duplicated.
• NOTE: Blue cards are for the Primary role, Pink for the Secondary role.
E.g. ‘Create Product Backlog Items’ – Blue (Primary) for PO, Pink
(Secondary) for Team.

30. “Scrum is free and offered in this guide,
Scrum’s roles, artifacts, events, and rules
are immutable and although
implementing only parts of Scrum is
possible, the result is not Scrum.”
Scrum Guide Oct 2011
http://www.scrum.org/Scrum-Guides

31. Immutable (Cannot change)
Roles Ceremonies Artifacts Rules
1 x Scrum Master Sprint Planning Product Backlog Cross Functional
1 x Product Owner Daily Standup Sprint Backlog Self Organising
Developers Sprint Review
Potentially
Shippable
Increment
Max Sprint length
<= 1 month
Sprint
Retrospective

32. Mutable – some examples
Roles Ceremonies Artifacts Rules
Scrum Master also
contributes to
team
Planning involves
experts from other
teams
Not using User
Stories
T.D.D. mandated
for backend code.
Product Owner
across 2 teams
Standup uses
speaking token
Use a burn up
chart
Some team
capacity put aside
for defects
Demo done by diff.
team member
each week
No task board Co-location
Hold Retro in café. Using Use Cases

33. Co-location
• Not mandated in Scrum, however;
• Agile manifesto: 2 of 4 Values Statements and 1 Principle relate
to it.
• Generally accepted that it is a crucial success factor.

34. Co-location
Co-location results in:
• Significantly increased collaboration.
• Enhanced feeling of being in a team.
• Impediments being resolved faster.
• Reduces delays with the team.
• Overall Success!

35. Scrumbut
We do Scrum but ....
• We have two PO’s for our team.
• We need team X to finish each User Story.
• Retrospectives are a waste, so we don’t do them.
• Management keeps changing the Sprint Goals.

36. Success
What does a successful Scrum team look like?
• Delivering consistently.
• Regularly finishing their top priority stories first.
• Team actively managing Technical Debt.
• Collaborating extensively with PO.
• Try’s from Retrospectives result in change.
• Team rarely works overtime.

37. Scrum takeaways
Why: Faster Feedback, Find the Fun earlier, Reduce Crunch.
Roles: Scrum Master, Product Owner, Team Member.
Ceremonies: Planning, Backlog Refinement, Stand up, Review, Retrospective.
Artefacts: Product Backlog, Sprint Backlog, Burn-down, Product Increment.
Values: Focus, Courage, Commitment, Openness, Respect.
Other: Immutable rules, Co-location recommended

38. Questions?

39. User Stories

40. User Stories
• Why User Stories?
• Different Formats
• INVEST
• Vertical Slices
• Iterative and Incremental

41. Why use User Stories?
• Low overhead
• Encourage Collaboration
• Supportive of change

42. Format of User Stories
As a [USER]
I want [GOAL]
So that [BUSINESS BENEFIT]

43. Example User Story
As a Player who is new to Poker
I want to see tips pop up in game, that explain
good moves I missed out on making
So that I feel like I am learning and hence want to
keep playing

44. War Stories
• Stories about User Stories that have caused problems?
• What characteristics did those stories have?

45. What makes for a good User Story?
• Independent
• Negotiable
• Valuable
• Estimatable
• Small
• Testable

46. What is wrong with these Stories?
I want the phoenix animation to
be visually spectacular
As a regular bingo player
I want to be notified when I
have played for 30 minutes
So that I know when time is up
As a seasoned poker player
I want the tips on the flop to be
tested
As a normal roulette player
I want the roulette wheel
animation to glint at 60 degrees
from centre with a silver flash
on every second revolution
So that it seems more realistic
and engaging.

47. Component Approach
User Interface
Business Logic
Adapters
Services StoryDStoryCStoryB
StoryA

48. Vertical Slice
User Interface
Business Logic
Adapters
Services
StoryA
StoryB

49. Iterative & Incremental approach
Combines:
• Vertical Slices of Functionality
• Deferring non-functional aspects

50. 1 2 3
Building complete bits
“incrementing” builds a bit at a time

51. “iterating” builds a rough version, validates it, then slowly builds
up quality
1 2 3
Move from vague idea
to realization

52. Incremental, Iteration combines the ideas
1 2 53 4

53. User Stories takeaways
Why: Low overhead, Support Change, Encourage Collaboration.
Format: As a USER, I want GOAL, so that BUSINESS BENEFIT.
INVEST: Independent, Negotiable, Valuable, Estimatable, Small,
Testable.
Splitting: Incremental & Iterative and Vertical Slices.

54. Questions?

55. Agile Estimation

56. Agile Estimation
• What is it?
• Story Points
• Planning Poker

57. Human Capabilities for estimating
Roughly how long is this line?
Is this line, twice as long as the previous line?

58. What is Agile Estimation?
• Relative Estimation
• Uses team knowledge
• Focus on speed over accuracy

59. Story Points
• Represent Size of a Story
• Size = Effort, Complexity and Doubt
• Relative to each other. i.e. 2 is twice the size of 1
• Maths holds, i.e. 1 + 2 = 3
Effort
Doubt
Complexity

60. Story Points vs. Time
Relative Sizing (Story Points)
is more accurate over a large sample compared to
Time Estimation (Hours or Days)
Story Points are also quicker
Effort
Doubt
Complexity

61. Story Points do not equate to Time
Complexity
1pt
8pts
Duration for Grads = 5 days Duration for Seniors = 5 days
Duration for Seniors = 1 day Duration for Grads = 30 days

62. Planning Poker
• Facilitated by Scrum Master
• 1st time the team selects a Reference story.
• Reference Story is allocated 2 or 3 story points.
• All future stories are compared to this story.

63. Planning Poker Process
1. PO Explains the User Story to be estimated.
2. Team members select card and place face down.
3. Entire team reveals cards at same time.
4. Discuss high and low numbers.
5. Repeat steps 2..4 until consensus is reached.

64. Planning Poker Number Scale
0 1 2 3 5 80.5

65. Exercise - Estimating Eating Fruit
• Apple (Reference Story, 2 Story Points)
• Banana
• Orange
• Mango
• ½ Watermelon
• Pomegranate
• Peach

66. Exercise – Estimating Cooking Meals
• You are now the Meal Cooking team.
• We produce high quality meals from raw ingredients.
• There is a bakery next door so all bread products are supplied by them.

67. Agile Estimation takeaways
• Relative Estimation
• Uses team knowledge
• Focus on speed over accuracy
• Story Points: Effort + Complexity + Doubt
• Story Points != Time
• Planning Poker
• Fast Estimation

68. Questions?

69. Product Backlog
Management

70. Product Backlog Management
• Ownership
• Prioritize by Value
• Prioritize by Risk

71. Ownership
• Everyone should feel ownership for the Product.
• Product Owner – is responsible for the backlog.
• Backlog is not locked down, anyone can add to it.
• Not a free for all.
• Product Owner considers all stakeholders, including the team.

72. Prioritise by Value
• To maximise ROI, should prioritise Value first.
• Need effective User Stories.
• PO assists the team by explaining the business value.

73. Prioritise by Risk Mitigation
• To reduce Product and Project risk, we need to tackle the unknowns.
• Team assists the Product Owner by explaining these risks.
• Technical Debt should also be considered

74. Combined result
1. Early: Reduce Product and Project Risk
2. Middle: Focus on Value
3. End: Trim the tail

75. Exercise – Prioritising the City Break Backlog

76. Velocity
• Post Measure of delivery rate of the Team.
• Velocity = Sum of Story Points of User Stories that got to ‘Done’.
• Will fluctuate
• Average Velocity is useful guide

77. What happens with undone Stories?
• Do not count towards velocity.
• Carry over to next planning meeting, either included or dropped.
• Count towards velocity in the sprint that they are done.
• Velocity will fluctuate but will average out.

78. Product Backlog takeaways
• PO owns the backlog, but anyone can add to it
• Backlog prioritisation balances Value delivery with Risk mitigation

79. Questions?

80. Continuous
Development

81. Continuous Development
• Sequential vs. Continuous
• Approaches

82. Sequential development
Sprint N Sprint N + 1 Sprint N + 2

83. Continuous Development
• Scrum teams do a little of everything at once: Design, FE, BE, QA.
• Hence different approaches are needed
Sprint N Sprint N + 1 Sprint N + 2

84. Approaches for Continuous Development
• Iterative and Incremental User Stories
• Evolutionary design and architecture
• Management of Technical Debt
• Technical Practices
• Agile testing

85. Iterative and Incremental User Stories
• Covered in a previous section

86. Evolutionary Design & Architecture
• While some Design and Architecture will occur upfront
• It will also occur continuously throughout development
Evolutionary
Design &
Architecture
Continuous
Integration
Refactoring
Simple Design

87. Technical Debt
• What is Technical Debt?
• Who is responsible for Managing Technical Debt?

88. Technical Debt
• Team identify debt, raise User Story
• Write User Story in business terms
• Work with PO to prioritise the User Story

89. Technical Practices
• Version Control
• Coding Standards
• Code Reviews
• Refactoring
• Test Driven Development (TDD)
• Continuous Integration (CI)
• Simple Design
• Pair Programming
• Acceptance Test Driven Development (ATDD)

90. Traditional Testing vs. Agile testing
Conformance to
Requirements.
Identify issues.
Quality meets the
Customers needs.
Maximise Value.

91. Agile testing
• Quality Assurance is a whole team responsibility.
• Test Specialists will focus on testing, but everyone
should be involved.
• Consider Testing from the very beginning.
• Focus on Repeatable, Fully Automated, Self Reporting
Testing.

94. Continuous Development takeaways
• Game Design, UX, Code Design, Architecture all occur continuously.
• Rigorous Technical Practices are needed.
• We need to manage our Technical Debt.
• Quality assurance is everyone's responsibility.

95. Questions?

96. Wrap up

97. Wrap Up
• Review
• Reference Material
• Other Available Workshops

98. Putting it all together
Agile Manifesto
Set of Values and Principles
You can be ‘agile’, you cannot do ‘agile’
Framework based on Scrum
Work and technology agnostic extensible framework that adheres to Agile Manifesto
You can do Scrum, if done well, you will be agile
Technical Practices
Code Reviews, TDD, CI, etc.
Make it possible to do Scrum
Other Practices
Co-location, User Stories, Story Points, etc.
Very effective extensions for Scrum
Organisational Management System
Rules, Practices, Portfolio Management, etc.
scaling of methodology, specific to your organisation

99. Summary of today
Agile manifesto: what is it, where it came from.
Scrum: roles, ceremonies, artefacts, rules.
User Stories: format, Acceptance, INVEST, Iterative & Incremental.
Agile Estimation: Story Points, Planning Poker, Fast Estimation
Backlog management: Ownership, Value, Risk.
Continuous Development: Design, UX, Practices, Testing, Tech.
Debt.

100. One thing you will take away
• Please take 2 minutes
• Write down one thing you will take away from today
• We will share them with the group

101. Reference Material

102. Other Available Workshops
Agile & Scrum
Workshop
Effective User Stories
Scrum
Master
Product
Owner
Software
Development
Workshops
Software Testing
Workshops
Agile Leadership
Workshop
Becoming a Technical
Leader