Introducton to Scrum


Published on

Introduction to Scrum
How to use Scrum in corporate environments:
- distributed teams
- multiprojects

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

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

No notes for slide
  • Zeggen dat er hier bij analisten veel oefeningen/spelletjes bijkomen.Ook bij ontwikkelaars spelletjes, maar veel minder.Hierna oefening Waterval doen!
  • Add waterfall linkTime axis with long cycles when are requirements document ready (finaal requirements...)Uitleg over de driehoek -> fix features, plan resources + schedule
  • Add waterfall linkTime axis with long cycles when are requirements document ready (finaal requirements...)Uitleg over de driehoek -> fix features, plan resources + schedule
  • Welke bestaan er? Eerst probleen solven.Lean, scrum, xp : difference and how dowe support them
  • Introducton to Scrum

    1. 1. Purpose:<br /> - Confront Traditional Approach (Waterfall) with “New” Agile Approach<br /> - Scrum as a Agile Project Approach<br /> - Introduction, terminology, processes<br /> - How it is used at TenForce<br /> - Demo of pmScrum, the supporting tool by TenForce <br />
    2. 2. TenForce<br />Scrum – an Agile Approach<br />
    3. 3. Agenda<br />Traditional Approach vs. Agile Approach<br />Scrum<br />Scrum via pmForce (demo)<br />
    4. 4. Project Management for Software development<br />Customer requirements<br />Cost & Budget<br />Teams<br />Project Methodology<br />Change requests<br />Time to Market<br />Resource availability<br />
    5. 5. Project Management for Software development<br /> Software development requires a methodology to structure, plan and control the processes of development<br /><ul><li>Need for Flexibility
    6. 6. Limit Overhead
    7. 7. Control & Management</li></ul>Customer requirements<br />Cost & Budget<br />Teams<br />Project Methodology<br />Change requests<br />Time to Market<br />Resource availability<br />
    8. 8. Traditional waterfall approach<br />Pre-Analysis<br />Analysis<br />Development<br />Testing<br />Delivery<br />Time<br />Ready for user test<br />
    9. 9. Problems with waterfall approach<br /><ul><li>Time-to-functionality is long
    10. 10. Responding to change is difficult and costly
    11. 11. Software quality at risk
    12. 12. Customer orientation is weak
    13. 13. Team member accountability is difficult</li></li></ul><li>New: The Agile Approach<br />Analyse<br />Design<br />Pre-Analysis<br />Implementation<br />2–4 weeks<br />Deliver<br />Develop<br />Test<br />Ready for user test<br />Time<br />
    14. 14. New “Agile” approach<br /><ul><li>Focus on short, iterative development cycles
    15. 15. Short time to functionality
    16. 16. High visibility of progress
    17. 17. Customer centricity
    18. 18. Efficient operational control: planning, progress, cost
    19. 19. Best practices industry-based frameworks</li></li></ul><li>New Agile – Which frameworks do exist<br />Generic: Agile Manifesto <br />Methods: Scrum, Xtreme Programming,...<br />Project Management<br />Scrum<br />Development<br />Analysis<br />XP<br />
    20. 20. Scrum<br /><ul><li>emerged in the early 1990s
    21. 21. is used since then to develop ‘complex’ products
    22. 22. is not a process nor a technique for building products
    23. 23. Scrum is a simple management framework for incremental product development using cross-functional, self organizing teams.</li></li></ul><li>Scrum in a nutshell <br /><ul><li>Split your organization </li></ul> into small, cross-functional, self-organizing teams<br /><ul><li>Split your work </li></ul> into a list of small, concrete deliverables <br /><ul><li>Sort the list by priority </li></ul> estimate the relative effort of each item<br /><ul><li>Split time into short fixed-length iterations (usually 1 – 4 weeks)</li></li></ul><li>Scrum Framework<br />Product Owner<br />The Team<br />ScrumMaster<br />Roles<br />Sprint Planning Meeting<br />Daily Stand-up<br />Sprint Review<br />Sprint Retrospective<br />Meetings<br />Product Backlog<br />Sprint Backlog<br />Burndown charts<br />Bug/Impediment List<br />Tools<br />
    24. 24. Roles<br />Plans the Sprint during sprint planning meeting<br />Owns the vision of what should be produced to achieve business success<br />Team<br />Turns input from stakeholders into a single list, called<br /> Product Backlog<br />Commits to the Sprint<br />Prioritizes list based on business value, ROI or level of risk<br />Delivers what is promised <br />ScrumMaster<br />Product Owner<br />Self-Organizing<br />Takes away impediments<br />Responsible for the business process<br />Coaches & facilitates<br />
    25. 25. Tools<br />Artifacts<br />List of user stories & its tasks to deliver the stories<br />Product Backlog<br />Burndown Charts<br />Filled with stories to be developed in the sprint<br />Team is owner<br />Measurement of remaining work<br />Prioritized list of user stories<br />Estimated in relative weights (story points)<br />Per Sprint/Project<br />PO is owner<br />Sprint Backlog<br />
    26. 26. Meetings<br />Sprint Review (demo)<br />Ceremonies<br />Demo the delivered software<br />Planning Meeting<br />End of each sprint<br />Productlog is discussed and explained<br />PO, SM, Team, <br />Other Stakeholders<br />Sprint Backlog is created<br />Daily Stand-up<br />Sprint Retrospective<br />PO, SM & Team<br />Daily follow up<br />Stand stil to reflect on passed sprint<br />SM & Team<br />What went good? What could have been done better?<br />Take Action!<br />What have you done?<br /> What did impedes you? <br />What will you do?<br />SM, Team, (PO)<br />
    27. 27.
    28. 28. Kick Off – Initial Product Backlog<br /><ul><li>Requirements in user stories (processes)
    29. 29. As a team manager, I want an overview of all work assigned to my team so I can check capacity
    30. 30. As a DBA, I want a polling mechanism on DB K43 to make sure it stays under 85% usage</li></ul>- As a user, I want a button to refresh screen<br />
    31. 31. Initial Product Backlog<br /><ul><li>Rough estimates
    32. 32. Strict(!) Prioritization
    33. 33. During Project, stories are refined
    34. 34. Six weeks ahead</li></li></ul><li>Sprint Planning<br /><ul><li>Discuss stories with highest priority
    35. 35. The team estimates using Planning Poker
    36. 36. Sprint is planned
    37. 37. Team commits as a team</li></li></ul><li>Planning Poker<br /><ul><li>After discussion, every one estimates relatively
    38. 38. Estimates are compared
    39. 39. If differences discussions
    40. 40. Re-estimate</li></ul>40<br />0<br />2<br />?<br />20<br />3<br />1/2<br />1<br />100<br />13<br />5<br />8<br />
    41. 41. Daily Stand-up<br /><ul><li>Daily Stand-up
    42. 42. Estimate Time to Complete (ETC)
    43. 43. What have you done, what will you do, what impedes you?
    44. 44. Peer pressure
    45. 45. Sprint Task Board</li></li></ul><li>Scrum Taskboard<br />
    46. 46.
    47. 47. Sprint Review (Sprint Demo)<br /><ul><li>All stakeholders invited
    48. 48. Present finished work (“Done”)
    49. 49. Feedback moment </li></ul> on working software<br />“The only proof of progress <br /> is working software”<br />
    50. 50. Sprint Retrospective<br /><ul><li>Evaluate Sprint
    51. 51. Continuous improvement</li></li></ul><li>Demo<br />
    52. 52. Questions?Remarks?<br />You can implement it. We can help.<br />
    53. 53. TenForce<br />The Pragmatic Company<br /><br />TenForceHaachtsesteenweg 378<br />1910 KampenhoutBelgium<br />http://www.tenforce.cominfo@tenforce.comTel +32 (0)16 31 48 60Fax +32 (0)16 65 90 85<br />