Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Scrum - Atlanta Code Camp

Scrum is not a new concept but it has gained a lot of popularity in the last few years. It is a very powerful agile project management methodology that, when used correctly, can help your team deliver better software faster than before. We will start with a brief overview of the process and look at some techniques and tools that will help you succeed, as well as common pitfalls that you should avoid. Come prepared for an interactive session where you will be encouraged to share your experiences with Scrum.

  • Login to see the comments

  • Be the first to like this

Scrum - Atlanta Code Camp

  1. 1. Scrum<br />Intro and overview<br />
  2. 2. What is Scrum?<br />Agile development methodology<br />Helps cross-functional teams commit and deliver high-quality, production-ready code in phases<br />Scrum 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. <br />Scrum engages developers to produce the major pieces of an application in less time than by traditional methods<br />
  3. 3. Characteristics<br />Self-organizing teams<br />Product progresses in a series of two- to four-week “sprints”<br />Requirements are captured as items in a list of “product backlog”<br />No specific engineering practices prescribed<br />Uses generative rules to create an agile environment for delivering projects<br />One of the “agile processes”<br />
  4. 4. Scrum goals<br />Team environment & communication<br />Quality product<br />Provide more information on project progress early on<br />Ability to adjust to business needs<br />
  5. 5. Traditional Approach<br /><ul><li>Time is spent on every phase, but the client doesn’t see any benefit until the end
  6. 6. Major changes due to business needs are not easily incorporated into the design
  7. 7. QA does not get involved until the end which results in very costly bug fixes</li></li></ul><li>Using Scrum<br />
  8. 8. Time boxes<br />Release Planning Meeting<br />Sprint<br />Sprint Planning Meeting<br />Sprint Review<br />Sprint Retrospective<br />Daily Scrum<br />
  9. 9. Process<br />Sprint planning meeting<br />Allows product owner and team to see what will be delivered<br />Team addresses “What” and “How”<br />Sprint goal is set<br />Items are moved from the product backlog into a sprint<br />Sprint backlog is created<br />
  10. 10. Process<br />Daily Scrum meetings<br />Allows team to see entire picture everyday<br />Short meeting, team members answer the following:<br />What did I work on since the last meeting?<br />What will I work on until we meet again?<br />What impediments are preventing me from getting my tasks done?<br />Not a status meeting<br />
  11. 11. Process<br />Sprint review meeting<br />Occurs at the end of the sprint<br />Product is demo’d<br />Product owner can accept/reject the deliverables<br />Review Product backlog at the end<br />
  12. 12. Process<br />Sprint retrospective<br />Discuss what went well and what to improve in the next sprint<br />Team is encouraged to revise processes in order to become more effective on the following sprint<br />Inspect how the last Sprint went in regards to people, relationships, process and tools<br />The product owner does not attend this meeting.<br />Start/Stop/Continue<br />
  13. 13. Team dynamics<br />Self-organizing teams<br />No one person is in charge of the team’s decisions<br />Team is responsible for committing and delivering<br />Cross-functional teams (BSA, QA, developers, PM)<br />
  14. 14. Backlogs<br />Product Backlog<br />The requirements for a system<br />Prioritized list <br />Includes both functional and non-functional customer requirements, as well as technical team-generated requirements. <br />Sprint Backlog<br />Defines the work for a sprint<br />Represented by the set of tasks that must be completed to realize the sprint's goals<br />
  15. 15. Burn-down chart<br />Tracks how much value has yet to be delivered<br />Work remaining is the Y axis and time is the X axis<br />Sprint burn-down charts show daily progress<br />Product burn-down chart show monthly (per sprint) progress.<br />
  16. 16. Burn-down chart<br />
  17. 17. Done<br />Every sprint should produce “potentially shippable” code<br />Team must define what “Done” means to them<br />Everyone should have the same understanding of “Done”<br />
  18. 18. Let’s build a website!<br />An E-commerce website is needed for your sportswear company<br />Product Backlog:<br />
  19. 19. 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 />
  20. 20. Calculating Velocity<br />
  21. 21. Burndown Chart<br />
  22. 22. Velocity Chart<br />
  23. 23. Quality<br /> Focus on creating “production ready” deliverables at the end of each sprint<br />Product is designed, coded, unit tested, peer reviewed, built and QA tested during the sprint<br />Never sacrifice quality<br />If an item cannot be delivered, negotiate with project owner<br />It should be apparent early in the process if something will not be delivered<br />A sprint should always run through completion to maintain quality of code base.<br />At the end of each spring, a decision can be made regarding the direction of the project.<br />Lack of focus on quality reduced efficiency over time<br />
  24. 24. Communication<br />Sprint planning meetings allow the project owner and team to see what will be delivered and have a common “Sprint Goal”<br />Sprint back-log is updated daily to show progress and possible estimation errors<br />Sprint burn-down chart shows progress throughout the sprint (generated from the sprint back-log)<br />Daily scrum meetings foster communication about daily tasks and allows the entire team to assess the project on a daily basis<br />
  25. 25. Tools – Planning Poker<br />Combines expert opinion, analysis to provide quick/reliable estimates<br />Includes entire team<br />Use special cards or modified playing card <br />Have fun<br />
  26. 26. Tools – Task Board<br />Source:<br />
  27. 27. Software Tools<br />Whiteboard<br />Excel<br />TFS (Scrum Templates)<br />TeamPulse<br />ScrumWorks<br />Rally Software<br />
  28. 28. 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 />
  29. 29. 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 />