Demystifying Scrum, the intent is to provide a general overview to those unfamiliar with the terms and jargon associated with Agile and Scrum This presentation will cover three main topics: 1. The key differences between Agile versus Waterfall Project Delivery 2. The core features of Scrum 3. The key concepts of Scrum Speaker - Ben McDonnell Ben McDonnell is the Capability Lead for Business Analysis at Expose. He has worked with multiple state, local and federal Government Agencies as well as utilities, mining and energy, and defence. He is currently working on an Agile Project in partnership with the Department for Education which will be used as a real case study of SCRUM for this presentation. We look forward to seeing you there!

1. IIBA® Adelaide
Demystifying SCRUM
15 June 2023
IIBA® Global 2022 Chapter of the Year

2. UNOFFICIAL
Welcome

3. UNOFFICIAL
IIBA® Australia acknowledges the Traditional Owners of
country throughout Australia and recognise their continuing
connection to land, waters and culture.
We pay our respects to Elders past, present and emerging
and extend our respects to all Aboriginal and Torres Strait
Islander people present with us today.
Acknowledgement of Country

4. UNOFFICIAL
For more information and to register visit
https://australia.iiba.org/events-list
National Future Events
20 June 2023
IIBA® Brisbane | In-Person Event
Navigating through the Maze: Trust and Performance Boost
26 June 2023
IIBA® Perth | In-Person Event
Pimp my chart with Jacob Hammer
28 June 2023
IIBA® Sydney | In-Person Event
The linchpin in decision making

5. UNOFFICIAL
For more information and to register visit
https://australia.iiba.org/events-list
SA Future Events
17th August 2023
IIBA® Adelaide | In-Person Event
Value Prioritisation
23rd November 2023
IIBA® Adelaide | In-Person Event
LEAN Coffee

6. UNOFFICIAL
Festival of Business Analysis
16 – 20 of October 2023
Australia & New Zealand
https://festivalofbusinessanalysis.org

7. UNOFFICIAL
Study Groups
20 June 2023
IIBA® Adelaide | In-Person
Agile Analysis Study Group
12 July 2023
IIBA® Brisbane | Online
Agile Analysis Study Group

8. UNOFFICIAL
IIBA® Sydney Mentors and Mentees
17 July – 20 November 2023 | In-Person
If you are interested and would like to express your interest in becoming a mentor
or mentee please scan the QR codes or visit the link below:
Mentoring Program

9. UNOFFICIAL

10. UNOFFICIAL
Call for Volunteers
The IIBA Australia Chapter invites your expressions of interest (EOI) to join and support
us in providing our services to our members and community. Chapter volunteering is
activity and capacity based. In addition to completing this form, you are strongly
encouraged to get involved by attending Chapter events held in your local city.
For more information and to express your interest visit:
https://australia.iiba.org/volunteer

11. UNOFFICIAL
Follow us on Social Media
Join the Conversation NOW!
IIBA Australia IIBA Australia Chapter
@IIBAAUS
iiba_australia IIBA Australia
Chapter Ltd
iibaaustralia.com

12. 1 5 J u n e 2 0 2 3
UNOFFICIAL
Demystifying
Scrum
D
e
m
y
s
t
i
f
y
i
n
g
S
c
r
u
m

13. 1 5 J u n e 2 0 2 3
UNOFFICIAL
D
e
m
y
s
t
i
f
y
i
n
g
S
c
r
u
m

14. 1 5 J u n e 2 0 2 3
UNOFFICIAL
Waterfall methodology
P
r
e
s
e
n
t
a
t
i
o
n
T
i
t
l
e

15. 1 5 J u n e 2 0 2 3
UNOFFICIAL
Waterfall methodology
Analysis
Program
Design
Software
Requirements
System
Requirements
Coding
Testing
Operations
Analysis
Coding
Source: Managing the development of large software
systems.
W. W. Royce (PhD), 1970
In 1970, Dr Winston Royce, identified that most successful
projects where analysis was done before coding

16. 1 5 J u n e 2 0 2 3
UNOFFICIAL
Waterfall methodology
Source: Managing the development of large software
systems.
W. W. Royce (PhD), 1970

17. 1 5 J u n e 2 0 2 3
UNOFFICIAL
So, what went wrong?
The Department of Defence defined a standard that stipulated
the Waterfall method but using a non-iterative approach.
Waterfall methodology
Analysis
Program
Design
Software
Requirements
System
Requirements
Coding
Testing
Operations
Source: Managing the development of large software
systems.
W. W. Royce (PhD), 1970

18. 1 5 J u n e 2 0 2 3
UNOFFICIAL
Agile approach
P
r
e
s
e
n
t
a
t
i
o
n
T
i
t
l
e

19. 1 5 J u n e 2 0 2 3
UNOFFICIAL
Agile – a mindset, not a methodology
In early Spring of 2001, a group of developers (and one
tester) met in a Utah ski resort to discuss how they could
speed up software development.
They recognised Change as the biggest influence on the
success or failure of a project.
They were looking for a lightweight approach to software
engineering that could adapt to changes and bring
software to market in months instead of years.

20. 1 5 J u n e 2 0 2 3
UNOFFICIAL
Agile
From this meeting, the ‘Agile Manifesto” was born…
They defined 4 core values:
1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiations
4. Responding to change over following a plan

21. 1 5 J u n e 2 0 2 3
UNOFFICIAL
A little later came the 12 Principles of Agile:
1. Early and continuous delivery of valuable software
2. Welcome changing requirements, even late in development
3. Deliver working software frequently
4. Business-people and developers must work together
5. Build people around motivated individuals
6. Face to face conversation
7. Working software is the primary measure of progress
8. Agile processes promote sustainable development
9. Continuous attention to technical excellence and good design enhances agility
10. Simplicity - the art of maximising the amount of work not done - is essential
11. Self-organising teams
12. Regularly reflects on how to become more effective

22. 1 5 J u n e 2 0 2 3
UNOFFICIAL
What do we mean by “Wagile”?
Essentially…
It means doing a Waterfall project with an iterative approach:
• Analysis and Design phase approach, in smaller ‘chunks’ rather than one big delivery.
• Roles and responsibilities intact but cut back on documentation and processes.
• Accepting that “change” is inevitable.

23. 1 5 J u n e 2 0 2 3
UNOFFICIAL
So… “Scrum”
P
r
e
s
e
n
t
a
t
i
o
n
T
i
t
l
e
Where does it fit in?
And what does this picture
mean?

24. 1 5 J u n e 2 0 2 3
UNOFFICIAL
Scrum in a nutshell (key features)
1. Lightweight framework
• Scrum does not dictate what documentation or coding standards to adhere to.
• The team itself defines that as part of their ‘agreed ways of working’
2. Iterative delivery (sprints) of working software
• Scrum teams work in short timeframes (from 1 week to a month) called ‘Sprints’.
• They flow on from one sprint to the next without a break.
• Each sprint will have a delivery goal that the team agrees to and the whole team works towards achieving that goal
3. Cross-functional teams
• A team is made up of people with a range of skills – business analysis, testing, development, etc.
• But… each person should (ideally) be able to help with other tasks outside of their speciality when the need arises.

25. 1 5 J u n e 2 0 2 3
UNOFFICIAL
Scrum in a nutshell (key features)
4. Regular reviews (retrospectives)
• At the end of each sprint, the team is expected reflect on the work that was done and seek to improve the process:
• Changing what needs to be changed, but also recognising what worked.
5. Close collaboration with delivery team and the business
• The business need to guide the delivery and correct the course early.
• Scrum defines the role of ‘Product Owner’ as the person that has the vision for the product.
• The Product Owner is in charge of the backlog of work that the team will undertake.
6. Regular meetings (ceremonies) within each sprint
• Each sprint follows a pattern with a number of essential meetings (ceremonies):
• Sprint planning (at the start)
• Daily standup
• Sprint review (at the end)
• Retrospective (also at the end)

26. 1 5 J u n e 2 0 2 3
UNOFFICIAL
Scrum “Ceremonies”
The “Scrum Picture” thingy
Attempts to illustrate:
• the cyclic nature of sprints
• continual progress
• regular cycles of ‘ceremonies’ within
each sprint

27. 1 5 J u n e 2 0 2 3
UNOFFICIAL
Scrum “Ceremonies”
Sprint Planning
• Occurs on Day 1 of the sprint and involves the scrum team and the Product Owner (PO)
• The PO sets the priorities for the upcoming sprint
• The team pulls stories from the Product Backlog into the Sprint Backlog to work on to
meet those priorities
Daily Stand-up (Daily Scrum)
• Occurs once each day, and lasts around 15 minutes
• The team each report on the previous day’s achievements,
blockers and what they plan to achieve on the current day
Sprint Review
• Occurs at the end of the sprint
• The scrum team demonstrates what they have achieved
during the sprint to the Product Owner and other
stakeholders
Retrospective
• Occurs at the end of the sprint
• The scrum team looks back over the previous sprint and considers:
1) what worked well; 2) what didn’t; 3) what do we need to change?

28. 1 5 J u n e 2 0 2 3
UNOFFICIAL
Scrum concepts
P
r
e
s
e
n
t
a
t
i
o
n
T
i
t
l
e
Why don’t they just use plain English?

29. 1 5 J u n e 2 0 2 3
UNOFFICIAL
Why the jargon?
• “Ceremonies” instead of “Meetings”
• “Products” instead of “Projects”
• “Sprints”, “Cadence”, “Velocity”, “User Stories”, “Epics”…
It’s all about changing the way that you think about project delivery.
Remember: Agile is a Mindset, not a Methodology!

30. 1 5 J u n e 2 0 2 3
UNOFFICIAL
Sprint
• No, it doesn’t mean “run fast”
• At the time that Scrum was created,
software development was a marathon.
• The designers wanted to use something
shorter – i.e. a Sprint.
• Sprints are “time-boxed” events, That is,
they have a fixed duration.

31. 1 5 J u n e 2 0 2 3
UNOFFICIAL
Scrum Master
• Is this the Project Manager?
Kind of but not really.
• They are responsible for ensuring work is
done and removing blockers.
• They also help the squad understand
what Scrum is all about (act as a team
coach).

32. 1 5 J u n e 2 0 2 3
UNOFFICIAL
Backlog
• The pile of work your team has to do
• Used in a variety of contexts:
• Product Backlog
All of the tasks that are needed to do to
complete the development of the
product
• Sprint Backlog
The list of tasks that your team is currently
working on within this sprint.
These tasks are taken from the top of the
Product Backlog.

33. 1 5 J u n e 2 0 2 3
UNOFFICIAL
Product Owner
• Sort of a “Project Sponsor”, but not really.
• They guide the scrum team but don’t
lead them.
• They are the decision-makers and are
expected to be experts on what the
business wants.
• They are essential to the success of a
delivery team

34. 1 5 J u n e 2 0 2 3
UNOFFICIAL
User Stories
• These are packages of work not “requirements”
• The structure is intended to make you think like a
user rather than as a delivery team member
• User stories are self-contained packages of work
that define what the user wants to do and why.
• The story contains just enough information to
clearly articulate the need (acceptance criteria).
• The team then works together to decide how to
achieve the outcome.

35. 1 5 J u n e 2 0 2 3
UNOFFICIAL
Roles within Scrum
• The 3 roles within Scrum:
• Product Owner
• Scrum Master
• Delivery Team (3 – 9 people)
Note: nowhere does it say “Business Analyst”

36. 1 5 J u n e 2 0 2 3
UNOFFICIAL
Story Points
• A quick way to estimate relative sizes of
work packages – using a modified
Fibonacci sequence.
• The numbers themselves don’t represent
anything tangible, they are really for
comparing a new story to an existing
one.
• Other estimation techniques exist
(T-Shirt sizing) but this is quite common.
1
2
3 5 8
13
20
40
100

37. 1 5 J u n e 2 0 2 3
UNOFFICIAL
Common Myths
Agile = Scrum
Scrum is just one of many
different approaches that
can all be called Agile.
1
Agile means no documentation
Agile means ‘just enough’
documentation.
3
Scrum has no BAs or PMs
Roles in a Scrum team are
deliberately left unclear,
because everyone is
expected to be able to do
more than one thing, but the
tasks remain unchanged.
2
Agile is cheaper
Agile projects have the same
constraints as any other –
time, budget, and scope.
There’s just more opportunity
to stop early.
5
Scrum has no governance
It’s there, but it just isn’t as
formal as a waterfall project.
A lot of governance occurs
during the Sprint ceremonies.
4

38. 1 5 J u n e 2 0 2 3
UNOFFICIAL
D
e
m
y
s
t
i
f
y
i
n
g
S
c
r
u
m

39. 1 5 J u n e 2 0 2 3
UNOFFICIAL
P
r
e
s
e
n
t
a
t
i
o
n
T
i
t
l
e
Example of Scrum Delivery

40. 1 5 J u n e 2 0 2 3
UNOFFICIAL
Example of Scrum Delivery
NOTE: This is a fictitious example only
Pizza’s will not be provided - SORRY!

41. 1 5 J u n e 2 0 2 3
UNOFFICIAL
Introduction
• Product Owner: Helen
• Role: Subject Matter Expert – Know the Customer!
• Development Team: Ben (Presenter)
• Role: Deliver the catering for the Pizza Party
• Customers: IIBA attendees (You!)
• Role: Enjoy the Pizza Party
• Background:
• 36 attendees

42. 1 5 J u n e 2 0 2 3
UNOFFICIAL
Sprint 0
• Start with an idea:
• 1 pizza: 3 people
• 36 people = 12 Pizzas
• Better than a blank page:
• 3 Supreme (with the lot)
• 3 Meat Lovers
• 3 Vegetarian
• 3 Chicken Supreme
• Sprint Review / Feedback (Product Owner):
• Dietary requirements
• Not sure if flavours will suit everyone

43. 1 5 J u n e 2 0 2 3
UNOFFICIAL
Sprint 1
• Learn from feedback:
• Allergies and dietary requirements:
• Gluten free / do not eat pizza
• Vegetarian
• Other Allergies?

44. 1 5 J u n e 2 0 2 3
UNOFFICIAL
Sprint 2
• Learn from feedback:
• Favourite flavours
• Supreme (with the lot)
• Meat Lovers
• Vegetarian
• Chicken Supreme
• Any other toppings?

45. 1 5 J u n e 2 0 2 3
UNOFFICIAL
Sprint 3 – Final Delivery
• Detailed requirements:
• 6 Gluten Free / Non-pizza
• Provide alternate options
• 2 less pizzas required
• 6 Vegetarian
• Minimum 2 Vegetarian pizzas required
• Ensure all other dietary requirements are accounted for
• Final delivery:
• 2 Supreme (with the lot)
• 2 Meat Lovers
• 4 Vegetarian
• 2 Chicken Supreme
• Hot chips
• Grilled chicken skewers

46. 1 5 J u n e 2 0 2 3
UNOFFICIAL
User Acceptance Testing
Final delivery:
2 Supreme (with the lot)
2 Meat Lovers
4 Vegetarian
2 Chicken Supreme
Hot chips
Grilled chicken skewers

47. 1 5 J u n e 2 0 2 3
UNOFFICIAL
D
e
m
y
s
t
i
f
y
i
n
g
S
c
r
u
m

48. Thank you