A Glance at Scrum and introduction to the most popular Agile framework.

1. SCRUM AT A GLANCE
M. ICHSAN RAHARDIANTO

2. SCRUM?
• Scrum is an Agile framework, its not a methodology
• Scrum is used for developing and sustaining complex products
• Scrum is founded on empiricism that asserts knowledge comes from what is known
• Adaptation, transparency, inspection uphold empirical process control
• Through iterative and incremental approach Scrum optimize predictability and control risk
• Scrum consist of Scrum Team, and their associated roles, events, artifacts and rules

3. TRADITIONAL VS SCRUM
Waterfall Scrum
images source http://scrumreferencecard.com/

4. WHEN SCRUM IS APPROPRIATE?
• When requirements is uncertain
• Unpredictable technology implementation
• Work is too complicated for the defined
process
• Software development is a perfect example
where iterative and incremental scrum
approach would provide benefits
image source http://scrumreferencecard.com/

5. WHY SCRUM?
• Scrum delivers product quickly
• Product delivered in highest possible value
• Scrum promotes transparency, everybody shares
common understanding
• Changes are welcomed, thus clients received
more desirable and suitable outcome
• Scrum limits risk per iteration of sprints
• Motivated and inspired team member
image source https://calvinx.com/

6. ITERATIVE AND INCREMENTAL
image source http://www.aspe-roi.com/

7. image source http://blog.presentationload.com/

8. SCRUM EVENTS
• Sprint planning
• Daily scrum
• Sprint review
• Sprint retrospective
image source http://www.rockstart.com/

9. SCRUM ARTIFACTS
• Product backlog
• Sprit backlog
• Increment
image source http://www.rockstart.com/

10. SCRUM PROCESS
image source http://www.modernrequirements.com/

11. M. ICHSAN RAHARDIANTO
ichsan.rahardianto@gmail.com
PLEASE SEE APPENDIX FOR MORE DETAILED INFO
appendix content is a summarize of scrum guide that can be found at http://www.scrumguides.org/

12. APPENDIX

13. SCRUM TEAM
• Scrum Teams are self-organizing and cross-functional
• Self-organizing teams choose how best to accomplish their work, rather than being directed
by others outside the team
• Cross-functional teams have all competencies needed to accomplish the work without
depending on others not part of the team
• Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for
feedback
• The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master

14. PRODUCT OWNER
• Clearly expressing Product Backlog items
• Ordering the items in the Product Backlog to best achieve goals and missions
• Optimizing the value of the work the Development Team performs
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the
Scrum Team will work on next
• Ensuring the Development Team understands items in the Product Backlog to the level
needed

15. DEVELOPMENT TEAM
• Consist of 3 – 9 members
• They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to
turn Product Backlog into Increments of potentially releasable functionality
• Development Teams are cross-functional, with all of the skills as a team necessary to create a
product Increment
• Scrum recognizes no titles for Development Team members other than Developer, regardless of
the work being performed by the person
• Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that
need to be addressed like testing or business analysis
• Individual Development Team members may have specialized skills and areas of focus, but
accountability belongs to the Development Team as a whole

16. SCRUM MASTER
• The Scrum Master is a servant-leader for the Scrum Team
• Ensuring the Scrum is understood and enacted
• Helps people outside the Scrum Team understand which of their interactions with the Scrum
Team are helpful and which aren’t, to maximize the value created by the Scrum Team

17. SCRUM MASTER TO PRODUCT OWNER
• Finding techniques for effective Product Backlog management
• Helping the Scrum Team understand the need for clear and concise Product Backlog items
• Understanding product planning in an empirical environment
• Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value
• Understanding and practicing agility
• Facilitating Scrum events as requested or needed

18. SCRUM MASTER TO DEVELOPMENT TEAM
• Coaching the Development Team in self-organization and cross-functionality
• Helping the Development Team to create high-value products
• Removing impediments to the Development Team’s progress
• Facilitating Scrum events as requested or needed
• Coaching the Development Team in organizational environments in which Scrum is not yet
fully adopted and understood

19. SCRUM MASTER TO ORGANIZATION
• Leading and coaching the organization in its Scrum adoption
• Planning Scrum implementations within the organization
• Helping employees and stakeholders understand and enact Scrum and empirical product
development
• Causing change that increases the productivity of the Scrum Team
• Working with other Scrum Masters to increase the effectiveness of the application of Scrum
in the organization

20. SCRUM EVENTS
• All events are time-boxed events, such that every event has a maximum duration
• Sprint duration is fixed and cannot be shortened or lengthened
• There are Sprint Planning, Daily Scrum, Sprint Review, Spring Retrospective, and Product
Backlog Refinement
• Other than the Sprint itself, which is a container for all other events, each event in Scrum is a
formal opportunity to inspect and adapt
• Failure to include any of these events results in reduced transparency and is a lost
opportunity to inspect and adapt

21. THE SPRINT
• Each Sprint may be considered a project with no more than a one-month horizon
• Sprint results “Done”, useable, and potentially releasable product Increment
• Sprints best have consistent durations throughout a development effort
• A new Sprint starts immediately after the conclusion of the previous Sprint
• Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the
Sprint Review, and the Sprint Retrospective
• Quality goals do not decrease, No changes are made that would endanger the Sprint Goal
• Scope may be clarified and re-negotiated between the Product Owner and Development
• A Sprint can be cancelled before the Sprint time-box is over. Only by the Product Owner

22. SPRINT PLANNING
• The work to be performed in the Sprint is planned at the Sprint Planning
• This plan is created by the collaborative work of the entire Scrum Team
• Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint
• What can be delivered in the Increment resulting from the upcoming Sprint?
• How will the work needed to deliver the Increment be achieved?
• This is where Sprint Goal is crafted. The Sprint Goal is an objective set for the Sprint that can
be met through the implementation of Product Backlog

23. DAILY MEETING (DAILY SCRUM)
• 15-minute time-boxed event for the Development Team to inspect and adapt
• Development team answers 3 questions for themselves :
• What did I do yesterday that helped the Development Team meet the Sprint Goal?
• What will I do today to help the Development Team meet the Sprint Goal?
• Do I see any impediment that prevents me from meeting the Sprint Goal?

24. SPRINT REVIEW
• Four-hour time-boxed meeting for one-month Sprints
• Attendees include the Scrum Team and key stakeholders invited by the Product Owner
• During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in
the Sprint, attendees collaborate on the next things that could be done to optimize value
• Development Team demonstrates the work that it has “Done” and answers about the Increment
• The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion
dates based on progress to date (if needed)
• The result of the Sprint Review is a revised Product Backlog that defines the probable Product
Backlog items for the next Sprint
• Informal meeting, not a status meeting, intended to elicit feedback and foster collaboration

25. SPRINT RETROSPECTIVE
• Three-hour time-boxed meeting for one-month Sprints
• Opportunity for the Scrum Team to inspect itself and create a plan for improvements
• The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning
• Inspect how the last Sprint went with regards to people, relationships, process, and tools
• Identify and order the major items that went well and potential improvements
• Create a plan for implementing improvements to the way the Scrum Team does its work

26. PRODUCT BACKLOG REFINEMENT
• Informal event that covers the refinement of the product backlog
• Scrum Team decides how and when refinement is done
• Refinement usually consumes no more than 10% of the capacity of the Development Team
• Increase visibility of product backlog that were likely to make it into the next sprint

27. SCRUM ARTIFACTS
• Scrum’s artifacts represent work or value
• Provide transparency and opportunities for inspection and adaptation
• Maximize transparency of key information so that everybody has the same understanding of
the artifact
• Scrum artifacts consist of Product Backlog, Sprint Backlog, and Increment

28. PRODUCT BACKLOG
• The single source of requirements for any changes to be made to the product
• The Product Owner is responsible for the Product Backlog, including its content, availability,
and ordering
• The Product Backlog lists all features, functions, requirements, enhancements, and fixes
• Product Backlog items can be updated at any time by the Product Owner or at the Product
Owner’s discretion
• Higher ordered Product Backlog items are usually clearer, more detailed, more precise
estimates and more likely to be included in the next Sprint than lower ordered ones
• The Development Team is responsible for all estimates

29. MONITORING PROGRESS TOWARD A GOAL
• At any point in time, the total work remaining to reach a goal can be summed
• The Product Owner tracks this total work remaining at least every Sprint Review
• The Product Owner compares this amount with work remaining at previous Sprint Reviews to
assess progress toward completing projected work by the desired time for the goal
• This information is made transparent to all stakeholders
• Various projective practices upon trending have been used to forecast progress, like
burndowns, burn-ups, or cumulative flows. These have proven useful
• However, these do not replace the importance of empiricism. In complex environments, what
will happen is unknown. Only what has happened may be used for forward-looking decision-
making

30. SPRINT BACKLOG
• The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for
delivering the product
• Is a forecast by the Development Team about what functionality will next Sprint results and
the work needed to deliver that functionality into a “Done” Increment.
• The Development Team modifies the Sprint Backlog throughout the Sprint
• This emergence occurs as the Development Team works through the plan and learns more
about the work needed to achieve the Sprint Goal
• Belongs solely to the Development Team

31. MONITORING SPRINT PROGRESS
• At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be
summed
• The Development Team tracks this total work remaining at least for every Daily Scrum to
project the likelihood of achieving the Sprint Goal
• By tracking the remaining work throughout the Sprint, the Development Team can manage its
progress

32. INCREMENT
• The Increment is the sum of all the Product Backlog items completed during a Sprint and the
value of the increments of all previous Sprints
• New Increment must meet the Scrum Team’s definition of “Done”
• Must be in useable condition regardless of whether the Product Owner decides to actually
release it

33. DEFINITION OF “DONE”
• When a Product Backlog item or an Increment is described as “Done”, everyone must
understand what “Done” means
• Scrum Team must have a shared understanding of what it means for work to be “Done”
• Guides the Development Team in knowing how many Product Backlog items it can select
during a Sprint Planning
• As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include
more stringent criteria for higher quality