Understanding Scrum in 30 Minutes


Published on

What is Scrum?
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

The Scrum Team
-The Product Owner
-The Development Team
-The Scrum Master

The Scrum Events / Rituals / Ceremonies
-Sprint Planning
-Daily Scrum
-Sprint Review
-Sprint Retrospective

Scrum Artifacts
-The Product BackLog
-The Sprint BackLog

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Understanding Scrum in 30 Minutes

  1. 1. Understanding Scrum in 30 Minutes by Altaf Al-Amin Understanding Scrum In 30 Minutes v1.0 is licensed under a Creative Commons Attribution-NoDerivs 3.0 Unported License.
  2. 2. Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Scrum is: •Lightweight •Simple to understand •Extremely difficult to master
  3. 3. Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development Game”, Harvard Business Review, January 1986. “The… ‘relay race’ approach to product development…may conflict with the goals of maximum speed and flexibility. Instead a holistic or ‘rugby’ approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements.”
  4. 4. Responsible for the product backlog and maximizing the product ROI. • Sole Person Not Committee • Represents the users (Business Owner) • Clearly expresses backlog items • Prioritize features according to market value • Ensures visibility • Defines features of the product • Decide on release date and content • Accept or reject work results • Authority on “What”
  5. 5. Responsible for delivering a potentially shippable increment of working software. • Self-organized • X functional • Not Titles Except Developer • Defines practices • 4 to 9 persons • Full Time Engagement • Authority on “How” to do “What” • No Sub Teams
  6. 6. Responsible for the scrum process • “Manager” but Servent-Leader • Enacting Scrum values • Services to Product Owner, Dev Team & Org • Team is functional • Removes impediments • Facilitates scrum events • Facilitates communication • Shield the team from external interferences
  7. 7. Walking around with Obstacles
  8. 8. Single source of requirements for any changes to be made to the product. • Living list that is never complete • Ordered: value, risk, priority & necessity • Estimated by the team • Product Backlog lists all features, functions, requirements, enhancements, and fixes
  9. 9. A subset of Product Backlog Items, which define the work for a Sprint Is created ONLY by Development Team Each Item has it’s own status Should be updated every day No more than 300 tasks in the list If a task requires more than 16 hours, it should be broken down Team can add or subtract items from the list. Product Owner is not allowed to do it Changes Team adds new tasks whenever they need to in order to meet the Sprint Goal Team can remove unnecessary tasks But: Sprint Backlog can only be updated by the team Estimates are updated whenever there’s new information
  10. 10. Used to assess when work is complete on the product increment. • Defined by the product owner • Unique for the whole team • Must allow immediate release • Quality increases with maturity
  11. 11. Two part time boxed meeting: 8hrs/1 Month sprint. 1. Defines what will be delivered in the increment • Team selects items from the product backlog and defines a sprint goal 2. Defines how the increment will be achieved – Sprint Backlog • Items are converted into tasks & estimated 1st Part: Creating Product Backlog Determining the Sprint Goal. Participants: Product Owner, Scrum Master, Scrum Team 2nd Part: Participants: Scrum Master, Scrum Team Creating Sprint Backlog
  12. 12. Busting Myth of Multi Tasking
  13. 13. Heart of Scrum •Time Boxed (2 to 4 weeks) •During the Sprint: •No changes are made that would affect the Sprint Goal •Development Team composition remains constant •Quality goals do not decrease; •Scope may be clarified and renegotiated between the Product Owner and Development Team as more is learned. •Each Sprint is Mini-Project •Limit the Risk to One Month of Cost •Only PO can cancel sprint before time
  14. 14. 15 minute time-boxed event for the Development Team to synchronize activities. • Development Team is responsible for conducting Meeting • Everyone Answers: • What has been accomplished since last meeting? • What will be done before the next meeting? • What obstacles are in the way? • Same Place, Same Time • Not Status Update but Commitment
  15. 15. Standing Survey
  16. 16. 4 hour time-boxed meeting / Month Sprint • Product owner identifies done / undone • Team discusses what went well, what problems it ran into & those that were solved • Team demonstrates what it has done in a demo • Product owner discusses the backlog as it stands • Entire group collaborates on what to do next • Result: Revised Product Backlog
  17. 17. Improves the process. • Sprint Review < Sprint Retrospective < Next Sprint Planning Meeting • Inspect how the last Sprint went PRPT (People, Relationship, Process, Tools) • 3 Hour / 1 Month Sprint • Identify and order the major items that went well & potential improvements • Create a plan for implementing improvements • Whole Team gathers and discusses – What they would like to • Start • Stop • Continue
  18. 18. Agile and Iterative Development: A Manager’s Guide by Craig Larman Agile Estimating and Planning by Mike Cohn Agile Project Management with Scrum by Ken Schwaber Agile Retrospectives by Esther Derby and Diana Larsen Agile Software Development Ecosystems by Jim Highsmith Agile Software Development with Scrum by Ken Schwaber and Mike Beedle Scrum and The Enterprise by Ken Schwaber