Succeeding with Scrum


Published on

Succeeding with Scrum presented at devLINK 2011.

Published in: Technology, Business
  • 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
  • Agile development methodologyHelps cross-functional teams commit and deliver high-quality, production-ready code in phasesScrum is an iterative process for developing any product or managing any work, which produces a potentially shippable set of functionality at the end of every iteration. Scrum engages developers to produce the major pieces of an application in less time than by traditional methods
  • Self-organizing teamsProduct progresses in a series of two- to four-week “sprints”Requirements are captured as items in a list of “product backlog”No specific engineering practices prescribedUses generative rules to create an agile environment for delivering projects
  • Team environment & communicationQuality productProvide more information on project progress early onAbility to adjust to business needs
  • Time is spent on every phase, but the client doesn’t see any benefit until the endMajor changes due to business needs are not easily incorporated into the designQA does not get involved until the end which results in very costly bug fixes
  • Sprint planning meetingAllows product owner and team to see what will be deliveredTeam addresses “What” and “How”Sprint goal is setItems are moved from the product backlog into a sprintSprint backlog is createdDaily Scrum meetingsAllows team to see entire picture everydayShort meeting, team members answer the following:What did I work on since the last meeting?What will I work on until we meet again?What impediments are preventing me from getting my tasks done?Not a status meetingSprint review meetingOccurs at the end of the sprintProduct is demo’dProduct owner can accept/reject the deliverablesReview Product backlog at the endSprint retrospectiveDiscuss what went well and what to improve in the next sprintTeam is encouraged to revise processes in order to become more effective on the following sprintInspect how the last Sprint went in regards to people, relationships, process and toolsThe product owner does not attend this meeting.Start/Stop/Continue
  • Self-organizing teamsNo one person is in charge of the team’s decisionsTeam is responsible for committing and deliveringCross-functional teams (BSA, QA, developers, PM)
  • Product BacklogThe requirements for a systemPrioritized list Includes both functional and non-functional customer requirements, as well as technical team-generated requirements. Sprint BacklogDefines the work for a sprintRepresented by the set of tasks that must be completed to realize the sprint's goals
  • Tracks how much value has yet to be deliveredWork remaining is the Y axis and time is the X axisSprint burn-down charts show daily progressProduct burn-down chart show monthly (per sprint) progress.
  • Every sprint should produce “potentially shippable” codeTeam must define what “Done” means to themEveryone should have the same understanding of “Done”
  • Focus on creating “production ready” deliverables at the end of each sprintProduct is designed, coded, unit tested, peer reviewed, built and QA tested during the sprintNever sacrifice qualityIf an item cannot be delivered, negotiate with project ownerIt should be apparent early in the process if something will not be deliveredA sprint should always run through completion to maintain quality of code base.At the end of each spring, a decision can be made regarding the direction of the project.Lack of focus on quality reduced efficiency over time
  • Sprint planning meetings allow the project owner and team to see what will be delivered and have a common “Sprint Goal”Sprint back-log is updated daily to show progress and possible estimation errorsSprint burn-down chart shows progress throughout the sprint (generated from the sprint back-log)Daily scrum meetings foster communication about daily tasks and allows the entire team to assess the project on a daily basis
  • Combines expert opinion, analysis to provide quick/reliable estimatesIncludes entire teamUse special cards or modified playing card Have fun
  • Succeeding with Scrum

    1. 1. Succeeding with Scrum<br />Esteban Garcia<br />
    2. 2.
    3. 3.
    4. 4. What is Scrum?<br />Agile development<br />Iterative<br />High-quality code<br />Shippable product with every iteration <br />High-priority features first<br />
    5. 5. Characteristics<br />Self-organizing teams<br />Sprints<br />Product Backlog<br />User Stories<br />
    6. 6. Goals<br />Team environment <br />Communication<br />Quality product<br />Transparency<br />Agility<br />
    7. 7. Traditional Approach<br />
    8. 8. The Problem<br />
    9. 9. Scrum Process<br />
    10. 10. Scrum Process<br />Release Planning Meeting<br />Sprint<br />Sprint Planning Meeting<br />Sprint Review<br />Sprint Retrospective<br />Daily Scrum<br />
    11. 11. Team dynamics<br />
    12. 12. Backlogs<br />Product Backlog<br />Sprint Backlog<br />
    13. 13. Burn-down chart<br />
    14. 14. Done<br />
    15. 15. Let’s build a website!<br />An E-commerce website is needed for your sportswear company<br />Product Backlog:<br />
    16. 16. Sprint backlog<br />Break down the tasks from the product backlog and make a commitment for the sprint: “As a user, I can view the company’s inventory”<br />
    17. 17. Calculating Velocity<br />
    18. 18. Burndown Chart<br />
    19. 19. Velocity Chart<br />
    20. 20. Quality<br />“Production Ready” after every sprint<br />Never sacrifice quality<br />Run sprints through completion<br />Re-assess often<br />
    21. 21. Communication<br />Sprint planning meetings<br />Sprint goal<br />Sprint back-log<br />Sprint burn-down chart<br />Daily scrum meetings<br />
    22. 22. Tools – Planning Poker<br />
    23. 23. Tools – Task Board<br />Source:<br />
    24. 24. Software Tools<br />Whiteboard<br />Excel<br />TFS (Scrum Templates)<br />TeamPulse<br />ScrumWorks<br />Rally Software<br />
    25. 25. Common pitfalls<br />Mini-waterfalls in each sprint<br />Making changes to the process before trying it out<br />ScrumMaster behaving as a team lead<br />Allowing sprints to go on longer than planned<br />Bug-creep<br />Developer-level burn-downs<br />QA not part of the process<br />
    26. 26. Conclusion<br />Scrum allows for better communication<br />Scrum helps with transparency<br />Scrum exposes existing problems and surfaces new problems as soon as they come up<br />Scrum helps you learn from the past<br />
    27. 27.<br /><br />@EstebanFGarcia<br />