fast Introduction scrum

2 272 vues

Publié le

This is a fast introduction to Agile Scrum that I created (from Mike Cohn Creative Common one) to bootstrap agility in a new team at Alcatel-Lucent.

Publié dans : Technologie, Sports
0 commentaire
3 j’aime
  • Soyez le premier à commenter

Aucun téléchargement
Nombre de vues
2 272
Sur SlideShare
Issues des intégrations
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • would be nice to include a quote from Wicked Problems here
  • fast Introduction scrum

    1. 1. One of Agile methods: “Scrum” – Wireless/LTE Alcatel-Lucent France Certified Scrum Master
    2. 2. Rugby instead of Relay race “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.” Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development Game”, Harvard Business Review, January 1986.
    3. 3. Agile origin
    4. 4. Scrum = most used Agile Methodology
    5. 5. Sequential vs. overlapping development Source: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986. Rather than doing all of one thing at a time... ...Scrum teams do a little of everything all the time Requirements Design Code Test T1 T1+d
    6. 6. Iterative & Incremental (iterate the whole)
    7. 7. AgileManifesto Weareuncovering better waysof developing softwareby doing it and helping othersdo it. Through thiswork wehavecometo value: Individualsand interactionsover processesand tools Working softwareover comprehensivedocumentation Customer collaboration over contract negotiation Responding to changeover following a plan That is, whilethereisvaluein theitemson theright, wevaluetheitemson theleft more.
    8. 8. Characteristics • Self-organizing teams • Product progresses in a series of 2-4 weeks “sprints” • Requirements are captured as items in a list of “product backlog” • No specific engineering practices prescribed nor forbidden • One of the “agile processes”
    9. 9. Agile Scrum rules
    10. 10. Putting it all together
    11. 11. Sprints • Scrum projects make progress in a series of “sprints” • Analogous to Extreme Programming iterations • Typical duration is 2–4 weeks • A constant duration leads to a better rhythm • Shorter sprint leads to faster impediment solutions • Product is designed, coded, and tested during the sprint
    12. 12. No changes during a sprint • Plan sprint durations as long as you can commit to keep change out of the sprint Change
    13. 13. Scrum framework •Product owner •ScrumMaster •Team Roles •Sprint planning •Daily scrum meeting •Sprint review •Sprint retrospective Rituals •Product backlog •Sprint backlog •Burndown charts Artifacts
    14. 14. Scrum framework •Sprint planning •Daily scrum meeting •Sprint review •Sprint retrospective Rituals •Product backlog •Sprint backlog •Burndown charts Artifacts •Product owner •ScrumMaster •Team Roles
    15. 15. Product owner role • Define the features of the product • Decide on release date and content • Be responsible for the profitability of the product (ROI) • Prioritize features according to market value • Adjust features and priority every iteration, as needed • Accept or reject work results
    16. 16. ScrumMaster role • Not a project manager but a facilitator • Responsible for Scrum values and practices • Removes impediments • Ensure that the team is fully functional and productive • Enable close cooperation across all roles and functions • Shield the team from external interferences
    17. 17. Team • Typically 5-9 people • Cross-functional: • Programmers, testers, user experience designers, etc. • Members should be full-time • May be exceptions (e.g., database administrator) • Teams are self-organizing • Ideally, no titles but rarely a possibility • Membership should change only between sprints
    18. 18. •Product owner •ScrumMaster •Team Roles Scrum framework •Product backlog •Sprint backlog •Burndown charts Artifacts •Sprint planning •Daily scrum meeting •Sprint review •Sprint retrospective Rituals
    19. 19. Sprint planning meeting Sprint planning • Analyze and evaluate product backlog • Create sprint backlog from product backlog items (user stories / features) • Estimate sprint backlog stories in relatives Story Points • Decompose stories in tasks • Evaluate tasks in days or hours. Sprint backlog Sprint backlog Business conditions Business conditions Team capacity Team capacity Product backlog Product backlog Techno- logy Techno- logy Current product Current product Inputs Outputs
    20. 20. Sprint planning Team selects items they can commit to finish from the prioritized product backlog • Sprint backlog is created • Stories are identified and decomposed in tasks • Each task is estimated such as it does last 1 or 2 days • Collaboratively, not done only by the ScrumMaster • Business value is considered (eg: Web travel agency) As a “tourist”(1), I want to “see photos of the hotel”(2) so that “I am sure it is near the sea”(3). As a “tourist”(1), I want to “see photos of the hotel”(2) so that “I am sure it is near the sea”(3). Code the database access (1 d) Code the user interface (2 d) Write test (1 d) Code the foo class (0.5 d) Update performance tests (2 d) (1): User role, (2): what to do, (3): business value
    21. 21. The daily scrum • Characteristics • Daily • 15-minutes • Stand-up • Everyone may come • BUT Only team members including ScrumMaster can talk • Goal • Keep the team synchronized and focused • Update the work done and burndown chart • Create a team spirit
    22. 22. Everyone answers 3 questions • These are not status for the ScrumMaster • They are commitments in front of peers What did you do yesterday?What did you do yesterday? 1 What will you do today?What will you do today? 2 Is anything in your way?Is anything in your way? 3
    23. 23. Sprint Demo/Review • Team presents what it accomplished during the sprint • Typically takes the form of a demo of new features • Informal • 2-hours prep time rule • No slides • Whole team participates • Everyone may come and discuss
    24. 24. Sprint retrospective • Take a look at what is and is not working • Typically less than 1 hour • Done after each sprint • Whole team participates • ScrumMaster • Team Start doingStart doing Stop doingStop doing Continue doingContinue doing
    25. 25. •Product owner •ScrumMaster •Team Roles Scrum framework •Sprint planning •Daily scrum meeting •Sprint review •Sprint retrospective Rituals •Product backlog •Sprint backlog •Burndown charts Artifacts
    26. 26. Product backlog • The requirements • A list of all desired work on the project • Ideally expressed such that each item has value to the users or customers of the product (user stories) • Prioritized by the product owner • Reprioritized at the start of each sprint This is the product backlog This is the product backlog
    27. 27. A sample product backlog Backlog Stories Estimate As a guest, I want to cancel a reservation. 5 As a guest, I want to change the dates of a reservation. 3 As a hotel employee, I can run RevPAR reports (revenue-per-available-room) 8 ... ... 30 ... 50
    28. 28. Managing the sprint backlog • Individuals sign up for work of their own • Work is never assigned by someone to someone • Estimated work remaining is updated daily • If work is unclear, define a sprint backlog item with a larger amount of time and break it down later • Update work remaining if you get more information – Either thanks to your work – By discussing with the Product Owner
    29. 29. Sprint backlog
    30. 30. Sprint Burndown Chart
    31. 31. Reading List • • • • Lots of weekly articles at • • French Scrum User Group:
    32. 32. Questions ?
    33. 33. Copyright notice • Adapted from Presentation of Mike Cohn You are free: to Share―to copy, distribute and transmit the work to Remix―to adapt the work • Under the following conditions • Attribution. You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work). • Nothing in this license impairs or restricts the author’s moral rights. • For more information see