The document provides a comprehensive overview of Scrum, outlining its framework, roles (Product Owner, Development Team, Scrum Master), and key principles such as self-organization and cross-functionality. It details the responsibilities of each role, Scrum events, artefacts, and essential practices for effective implementation, emphasizing the importance of transparency, inspection, and adaptation. Additionally, the document highlights common pitfalls, coaching strategies, and the necessity of aligning Scrum with broader organizational practices for optimal success.

1. SCRUM
Where to start

2. Who am I?
Andreea Visanoiu
• Scrum Master, Agile Coach
• Originally from Romania
• Lives in Kuala Lumpur
• Works for Mindvalley
• Former Product Manager / Product Owner
• Working with Agile for 7 years
• CSM, CSPO, Certified LeSS Practitioner
• Co-founder of Girls Who Code Romania

3. Agile vs.Waterfall

4. Waterfall vs Agile Software Development

6. The
SCRUM
Framework

7. Releasable increment

8. What is SCRUM?
Framework within which you can address complex adaptive
problems, while productively and creatively delivering product of
the highest possible value.
It is:
Lightweight
Simple to understand
Difficult to master
It consists of:
Teams & Roles
Events
Artefacts
Rules

9. The heart of SCRUM
…is EMPIRICISM => knowledge comes from experience and
making decisions based on what is known
What do you need to implement an empirical process control?
Transparency
Inspection
Adaptation

10. Scrum Values

11. SCRUM Team

12. Principles & Roles
Principles:
Self-organised:
• choose HOW to do the work
• no external direction / management
Cross-functional
• all competencies included
=> optimise flexibility, creativity, and productivity
Roles:
1. Product Owner
2. Development Team
3. Scrum Master

13. Product Owner

14. Product Owner’s Focus
Focus on one main thing: maximise VALUE of product.
One person - NOT committee.
No change in the PB / priorities can be done without the
PO.
Does & accountable for:
Product Vision: sketch of the final product
Roadmap: plan product versions
Product Backlog: groom, prioritise, explain, make sure it’s understood
Clarification of PB items for the Dev. Team
PB grooming
Not accountable for:
Sprint Backlog: not accountable but participates in the creation of it

15. Scrum Events to Attend
Mandatory:
Sprint Planning:
• You’re the only one who can tell the team what needs to be done
Sprint Review:
• You have to approve the increment / have stakeholders to approve
PB grooming:
• Not mandatory in Scrum guide but the best way to get the team
involved into the PB
Optional:
Daily Huddles
Sprint Retrospective

16. POs Common Mistakes
Underpowered PO: should be a mini-CEO
Overworked PO: too many product areas to control makes for bad
decisions
Partial PO: part-time POs can’t be part of the Scrum team
Distant PO: a PO that the team never sees or is never available for the
team will create a lot of impediments
Proxy PO: the real PO is too busy to do the work, so they assign a proxy;
as they’re not the decision makers, there will be delays in clarifications
PO committee: too many cooks spoil the broth :)

17. Reading List
More here: https://www.scrum.org/resources/suggested-reading-professional-scrum-product-owner

18. DevelopmentTeam

19. Development TEAM
Consists of:
Experts / professionals who work on delivering a
releasable increment
Size: min. 3 - max. 7 (not counting PO & SM)
Working method:
Self-organised: no one tells them HOW to turn the
PB into a releasable increment
Cross-functional: all skills necessary to build the
increment (e.g. coding, UX, design, data scientists,
etc.)
Accountability: to the team as a WHOLE

20. Responsibilities
Responsibilities:
Assess how much can be accomplished during a sprint (only the dev
team!)
Estimate duration of stories
Create Sprint Backlog from PB
Decide HOW to work on the items in SB
Create user stories & breaks them down into measurable units

21. Scrum Events to Attend
Mandatory:
Sprint Planning:
• The Dev Team does the estimation of Stories, breaks down the stories into tasks
/ sub-tasks, commits to the sprint goal and creates the Sprint Backlog
Daily Scrum:
• the Dev Team is responsible for conducting the Daily Scrum
Sprint Review:
• Collaborates with the POs and stakeholders about what was done in the sprint
and discuss the next thing to get done
• Also demonstrates the work done to stakeholders (no more boring sprint
reviews)
Sprint Retrospective:
• revision of the sprint, what went well, and what can be done to improve the
efficiency of the team and the joy of coding

22. Reading List
More here: https://www.scrum.org/resources/suggested-reading-professional-scrum-developer

23. Scrum Master

24. …IS
Servant Leader for the team
A Scrum evangelist and enforcer
Helping those outside the Scrum Team understand
which interactions are helpful and which aren’t
Coaching the Scrum Team, making sure they
deliver maximum value in the most effective way
Coaches the team members to make sure they
keep a healthy lifestyle and they find joy in their
work
Facilitates events and meetings for the teams
Pushes for team’s growth

25. Service to the PO
Finds ways for effective PB management
Helps the team understand the PB items
Ensures the PO knows how to prioritise items to maximise
value
Facilitates Scrum events as requested and needed

26. Service to the Development Team
Coach for self-organisation and cross-functionality
Helps the Dev Team create high-value products
Removes impediments to the Dev Team’s progress
Facilitates Scrum events as requested or needed

27. Service to the Organisation
Leads and coaches the organisation in its Scrum adoption
Plans Scrum implementations with the organisation
Helps employees and stakeholders understand and enact Scrum
Causes change that increases the productivity of the Scrum team
Works with other SMs to increase the effectiveness of the
application of Scrum in organisation

28. SM checklist
How is the Product Owner doing?
Is the PB prioritised?
Is value clear for each requirement?
Are the stakeholder’s requirements and desirements captured in the PB? (it’s a living
artefact)
Is the PB immediately visible to all stakeholders?
Is the release plan up to date?
How is my team doing?
Is your team in the state of flow?
Are they having fun while working?
Do they hold each other accountable?
Is the team focused on and reaching their Sprint Goals?
Is the team taking ownership of work as a whole?
How are our engineering practices doing?
Is your testing up to date?
Continuous delivery?
Continuous integration?
Waste?
Definition of Done?
How is my organisation doing?
Inter-team communication and collaboration?
Are you creating a learning organisation?
Is the rest of the organisation inducted in Scrum / Agile frameworks?
Find detailed checklist here: http://scrummasterchecklist.org/pdf/ScrumMaster_Checklist_12_unbranded.pdf

29. How about the
managers in Scrum?

30. What is the manager of a self-managed team to do?
• Has expertise in the domain area => helps team solve technical problems
• Coaches and helps the team individuals grow (feedback!)
• Represents team's interest in high level meetings and informs the team of any company strategy changes
• Cares for each member of the team and makes sure they have the right environment to deliver high quality
work
• Facilitates group events when needed
• Knowsof how the group works and taking active steps to help them work faster
• Creates an environment of trust, honesty and candid feedback for the team to feel safe
• Helps the team maintain focus
• Is an example through your own values, behaviour, energy, actions (e.g. we like our CTO, who’s a Wing Chun master,
former hacker, bitcoin expert and has a very dry British sense of humour; I like to hang out with him, and I also respect him for his knowledge
and expertise)

31. SCRUM Artefacts

32. Scrum Artefacts
Product backlog
Sprint Backlog
Releasable increment
Definition of DONE

33. Product Backlog
• Who owns it?
• PO and PB
• Development Team and PB
• Scrum Master and PB
• User stories (features) (E) - tasks (E) - sub-tasks - bugs

34. Product Backlog
A prioritised list of the work the team needs to complete to deliver the
Product vision.
PO’s accountability but the team as a whole should make sure the PB items are
the best choice for the product (PO has the final decision making power)
Living artefact: constantly updated, as development work happens; can be
updated anytime at the PO’s discretion
Lists all features, functions, requirements, enhancement, fixes the product needs
PB is one per product (even if multiple teams work on it)
The Dev Team is responsible for all estimates; the PO has final say on what
needs to be done

35. Activity
Create a Product
Backlog
Time: 15 minutes

36. Prioritisation
• What is value?
• Ownership
• Development Team’s role
• Product backlog refinement - essential meeting for a clean PB and for
team ownership of the PB

37. How to prioritise item in the PB
1. POs - Don’t do it alone, get the team involved (PBR)
2. Get together your team and the involved stakeholders and vision, goals, listen to
them, get them focused on goals, adjustments, answer questions, take action if
more research is needed, follow-up
3. Remember that it’s not possible that all items are a priority, it takes effort,
commitment, and it never stops
4. For complex and large projects, you should still be able to see some architecture
definition and design phasing early
5. Testing should be done throughout the development cycle, not close to the release
(deployment)
6. Riskier items should be surfaced, developed and tested earlier
7. References to research-oriented user stories - if not clear requirements
8. The team should actively contribute to refactor items, test automation, define
architectural and design items, rework items, get together packages of bug repairs
etc. => the Dev Team actively & continuously contributes to build the PB

38. Activity
Prioritise your PB
Organise stories in 3 iterations
Duration: 10 minutes

39. Sprint Backlog
A set of Product Backlog items selected for the Sprint & a plan
for delivering the product tIncrement and realising the Sprint
Goal
Entire responsibility lays on Dev Team
Estimation is made by the Dev Team only
It is modified / adapted only by the Dev Team during Sprint
If new work emerges during Sprint -> it is added to the Sprint
Backlog
As work is done, new estimations are made for the remaining work
Elements can be removed, if deemed unnecessary
=> a highly visible, real-time picture of the work the Dev Team will do
in the Sprint, that belongs solely to the Dev Team

40. Releasable Increment
The Sum of all PB items completed during a Sprint and the
value of the increments of all previous Sprints
The new Increment at the end of the Sprint must be “done”
Done = it must be in usable condition + meet the team definition of
“done”
It must be potentially releasable (not released, but if needed
ready to be released)

41. What is an MVP / MMF?

42. Building MVPs (or MMFs)

43. Building MVPs (or MMFs)
Breakdown of client needs:
• The client needs to go from A-B (let’s say 50 km)
• In under one hour, Every day, back and forth
• She also needs deposit space in case she does any shopping
• She needs extra space for friends in case he wants to take someone or bring someone along.
Client needs: to go from A-B (let’s say 50 km), in under one hour, every day, back and
fort; she also needs deposit space in case she does any shopping and space for friends
in case he wants to take someone or bring someone along.

44. Activity
Create the MVP for your product
(you can reprioritise the PB accordingly
Duration: 15 minutes

45. Definition of Done
• Everyone must have one understanding of what “done” means for an
Increment
• It is defined by the Development Team
• The organisation should one common definition of “Done”
• Each team can use the common definition to build their own definition of
“Done”, which incorporates the common checklist & ads to it
• “Done” is used to assess when work is complete on the product Increment
• It also guides the Dev Team when choosing how many PB items they can
work on during a Sprint

46. What is “DONE”?
Ken Schwaber’s definition of Done:
"Scrum requires Teams to build an increment of product functionality every
Sprint. This increment must be potentially shippable, because the Product
Owner might choose to immediately implement the functionality. This
requires that the increment consist of thoroughly tested, well-structured,
and well-written code that has been built into an executable and that the
user operation of the functionality is documented, either in Help files or in
user documentation. This is the definition of a “done” increment."

47. Activity
Create the
Definition of Done
for your team
Duration: 15 minutes

48. SCRUM Events

50. The Sprint
One month or less
Goal: a “Done”, useable, and potentially releasable product Increment is
created
Rules of Sprint:
• no changes are made that would endanger the Sprint goal
• quality goals do not decrease
• scope can be clarified and re-negotiated between the PO and Dev
Team
Sprint cancellations:
• can be done only by the PO, if the Sprint Goal becomes obsolete
• consume resources, as everyone has to regroup for a new Sprint
• are traumatic for the Scrum Team
• are (should be) very uncommon

51. Sprint Planning
Max. 4h for 2 weeks Sprints
Answers the questions:
• What can be delivered in the Increment resulting from upcoming
Sprint?
• Dev Team will decide how to work and how much work they can
take
• entire Team crafts the Sprint Goal
• How will the work needed to deliver the Increment be achieved?
• Dev Team creates Sprint Backlog
• stories should be decomposed to units (e.g. one day or less)
• PO helps to clarify the features, NOT telling the team how to work
• Define clearly the value that the sprint goal will bring to the company
(don’t get lost in BAU)

52. Daily Scrum
15-min max.
Answer 3 questions:
• What did I do yesterday to help the Dev Team meet the Sprint Goal?
• What will I do today to help the Dev Team meet the Sprint Goal?
• Is any impediment stopping me?
• Bonus Q4: What is your confidence, on a scale of one to ten, that the
team will accomplish the goal of this sprint?
In case a detailed discussion is needed: meet immediately after the Scrum
(also to adapt, re-plan, etc.)
The SM makes sure that the Dev Team has the meeting, but the Dev Team
is entirely responsible for it to happen

53. Sprint Review
2h meeting for two-weeks Sprints
Inspect the Increment
Adapt the Product Backlog
Key stakeholders need to participate to discuss the Increment
PO explains what has been done / not done in Product Backlog
Dev. Team discusses what went well & what didn’t
Dev. Team explains why it’s done and answer questions
Review Product Backlog and changes in requirements
Review of timeline, capabilities, budget, etc.
=> Product Backlog is updated following this meeting

54. Sprint Retrospective
Purpose:
• inspection the last Sprint (people, relationship,process, tools)
• identify what went well + improvements
• plan how to implement improvements
1.5h meeting for two-weeks Scrum
Scrum Master is conducting the event and ensure the time-box is
respected
Scrum Master documents and follow-up on the improvement ideas
Participants: SM & Dev. Team; PO optional (recommended to join)
=> how can we make Scrum more effective and enjoyable?

55. Product Backlog Refinement
One meeting held every sprint (mid-sprint ideally)
Refine items for maximum 2 - 3 sprints; don’t go to deep
High level estimations (to be consolidated in planning)
Most importantly: group discussion - everyone is involved in created the best
value for the customer (through the PB)
PB should be prioritised and organised before the meeting by PO
Understand the value of each item of the PB
A good PBR will make a better Planning
ALL Scrum Team should verify the PB routinely and input on the items

56. Open Discussion
What are next steps in your adoption of Scrum and Scrum values?
Duration: 15 minutes

58. SCRUM is not
enough

59. Scrum is not effective without…
• Managers as coaches
• Culture change - Agile mindset
• Coordination and collaboration
• Truly self-managed teams
• Engineering practices
• Experimenting
• Other frameworks’ tools (XP, Lean, Kanban)

60. Closing
• Expectations check
• Q&A

61. andreea.visanoiu@gmail.com
Andreea Visanoiu
+601 1226 8441