PM 201 Scrum Training


Published on

This training was developed to train a development team on the core fundamentals of Agile and Scrum processes for development.

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

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

No notes for slide

PM 201 Scrum Training

  1. 1. Project Management 201: Scrum & Agile Training John P Vajda Project Manager: PMP, CSM
  2. 2. Agenda <ul><li>Agile vs. Waterfall </li></ul><ul><li>The Principles of Agile </li></ul><ul><li>The Scrum Process </li></ul><ul><li>The Grocery Analogy </li></ul>
  3. 3. Agile vs. Waterfall
  4. 4. Agile vs. Waterfall The facts and figures <ul><li>Only 42% of requirements are ever implemented </li></ul><ul><li>66% of software functionality is rarely used </li></ul><ul><li>80% of a system is built after it’s first release </li></ul><ul><li>Only 16% of projects deliver on Time, on-budget, with all defined scope </li></ul>Source: Standish Report: 1994 Big Visible Scrum Training: 2009
  5. 5. Agile vs. Waterfall What is Wrong with Waterfall? <ul><li>Long duration between releases </li></ul><ul><li>Poor visibility into product and progress </li></ul><ul><li>Change is expensive and happens late in the cycle </li></ul><ul><li>Cannot quickly test new ideas </li></ul><ul><li>Risk increases over time </li></ul><ul><li>Cannot continuously re-evaluate investments </li></ul>
  6. 6. Agile vs. Waterfall So what can I do differently? <ul><li>Upfront requirements are wasteful and wrong: learn to work without all the details </li></ul><ul><li>Building software that is not used is expensive and wasteful: Don’t waste your time and money </li></ul><ul><li>Release earlier and faster! </li></ul><ul><li>Include your customers into your project team and get real time feedback </li></ul><ul><li>Embrace uncertainty </li></ul>
  7. 7. Agile vs. Waterfall What is right about Agile/Scrum? <ul><li>Scrum is an Agile process and is iterative </li></ul><ul><li>Can deliver the highest business value in the shortest time </li></ul><ul><li>Can rapidly and repeatedly inspect and adapt </li></ul><ul><li>Progress is measured in the form of working software </li></ul><ul><li>Customers can see real progress every 1 to 4 weeks </li></ul><ul><li>Allows you to actively pursue opportunities to improve </li></ul>
  8. 8. Agile vs. Waterfall A Visual Representation So this is how it looks…
  9. 9. The Agile Principles
  10. 10. The Agile Principles The Agile Manifesto Value Statement Individuals & Interactions Working Software Customer Collaboration Responding to Change over over over over Process & Tools Comprehensive Documentation Contract Negotiation Following a “Plan”
  11. 11. The Agile Principles What we adhere to and uphold: Agile Manifesto <ul><li>Change is good, welcome change </li></ul><ul><li>Frequent iterative delivery </li></ul><ul><li>Customer collaboration </li></ul><ul><li>It’s about people, get them what they need </li></ul><ul><li>Strive for the highest level of collaboration </li></ul><ul><li>Progress measured as a working product </li></ul><ul><li>Maintain a constant sustainable pace </li></ul><ul><li>Continuous attention to technical excellence and good design </li></ul><ul><li>Seek the simplest solution </li></ul><ul><li>Self Organizing Teams </li></ul><ul><li>Continue reflection and improvement </li></ul>
  12. 12. The Agile Principles (M)yths vs. (R)eality <ul><li>M : Agile is a “Cowboy free-for-all” </li></ul><ul><li>R : Agile is very rigorous in its principles </li></ul><ul><li>M : Agile does not scale </li></ul><ul><li>R: Agile has been scaled to hundreds of product developers </li></ul><ul><li>M : Agile is not for distributed teams </li></ul><ul><li>R : Agile supports the model of multiple distributed teams that adopt the same principals and practices </li></ul><ul><li>M : Agile = “No Documentation” </li></ul><ul><li>R : Agile stresses “necessary” product documentation </li></ul><ul><li>M : Agile ignores architecture </li></ul><ul><li>R : Agile stresses continuous architecture and design evolution </li></ul><ul><li>M : Agile means “No Planning” </li></ul><ul><li>R : Agile stresses the importance of short-term and long-term planning </li></ul>
  13. 13. The Scrum Process
  14. 14. The Scrum Process The Project Roadmap <ul><li>Projects comprise of multiple releases </li></ul><ul><li>Each release comprises of multiple sprints </li></ul><ul><li>Stories are started and completed within each sprint </li></ul><ul><li>Stories are executed based on value and priority </li></ul><ul><li>Value is set by Product Owners based on business need, cost, ROI, etc </li></ul>
  15. 15. The Scrum Process The Team and the Backlog <ul><li>Each Team has a ScrumMaster (Team Lead, Project Manager, Iteration Manager) </li></ul><ul><li>Each Team has a Product Owner (Product Manager, The Voice, The Business) </li></ul><ul><li>Each Team works from a Product Backlog </li></ul><ul><li>Each Team has a customer who can represent the user community </li></ul><ul><li>The Product Backlog is used to define what will be in each Sprint (iteration) </li></ul><ul><li>Each Sprint has a Sprint Backlog (iteration backlog) </li></ul>I am a product owner! I am a ScrumMaster! We are Developers! I am a customer!
  16. 16. The Scrum Process The Product Backlog <ul><li>Consists of high-level feature requirements, enhancements, etc. </li></ul><ul><li>Should have rough relative size estimates, not actual estimates </li></ul><ul><li>Should be prioritized correctly </li></ul><ul><li>Is expected to change throughout the project </li></ul><ul><li>Does not need to be perfect or complete </li></ul><ul><li>A Product Backlog Item (PBI) is also a Story </li></ul>
  17. 17. The Scrum Process The Product Backlog & Stories <ul><li>Follow the I.N.V.E.S.T Principle when creating a Backlog Item or Story! </li></ul>
  18. 18. The Scrum Process The Product Backlog & Stories <ul><li>It is really just a prioritized list! </li></ul><ul><li>Estimating shouldn’t only be time specific. It is good practice to size items by story points or arbitrary size values, that represent general size and complexity </li></ul><ul><li>This prevents estimate anchoring and allows the team to not get “hung up” on time </li></ul><ul><li>Discuss the story and indentify acceptance Criteria to determine when the story is finished </li></ul>3 Med (2-4) As a Guest I want to change dates of a reservation and have the new dates be visible so that if my meeting changes I can see the change dates in my meeting itinerary 2 Small (0-2) As I Guest I want to cancel a reservation and have it removed from my list of pending conference room bookings so that if my plans change, I can make adjustments on the fly. 1 Large (4 –6) As a Conference Room Coordinator I want to allow a Guest to make a reservation in the system so that we can book their request for a conference room in our system. Priority Estimate Backlog Item
  19. 19. The Scrum Process But Why Stories? <ul><li>Stories shift the focus from written to verbal communication </li></ul><ul><li>Stories avoid the need to put everything in writing upfront </li></ul><ul><li>Stories describe relatively small pieces of functionality that delivers business value </li></ul><ul><li>Stories are better suited for planning purposes </li></ul><ul><li>Stories are written in business language so users can understand and prioritize them </li></ul><ul><li>Stories avoid implementation detail or trying to provide a “technical solution” </li></ul><ul><li>Avoiding putting time on a story allows the team not get hung up on time </li></ul><ul><li>Range estimates work best </li></ul><ul><li>Small: 0 to 2 days </li></ul><ul><li>Medium: 2 – 4 days </li></ul><ul><li>Large: 4 to 6 days </li></ul><ul><li>X-large : 6 to 8 days </li></ul><ul><li>XX-Large : 8 to N Days </li></ul>
  20. 20. The Scrum Process How detailed do stories need to be? <ul><li>Don’t get hung up on details. Stories become more detailed as you move through Sprint Planning </li></ul>Like a Work Breakdown Structure 
  21. 21. The Scrum Process How do I plan my first sprint? <ul><li>Set a Sprint Duration (1 week to 4 weeks) </li></ul><ul><li>Plan your Target Velocity or the sustainable throughput of the project team (“Sustainable throughput” is simple the amount of backlog stories the team can successfully complete in each sprint) </li></ul><ul><li>Use the Product Backlog and the sized stories to determine your sprint plan </li></ul><ul><li>The team will need to commit to the amount of stories they can complete in the first sprint </li></ul>In this example, the team committed to 485 hours for Sprint #1 Now we know our Target Velocity! 
  22. 22. The Scrum Process More on Sprint Planning
  23. 23. The Scrum Process We are Sprinting! Now What? <ul><li>Now it’s time to work as a true Scrum team! </li></ul>
  24. 24. The Scrum Process More on the 15 Minute Daily Scrum <ul><li>Is 15 minutes enough? Why everyday? </li></ul><ul><li>Can I move this meeting around? </li></ul><ul><li>What if the team needs more time to collaborate? </li></ul>
  25. 25. The Scrum Process More on Sprint Reviews and Retrospectives
  26. 26. The Scrum Process What about “milestones” during a Sprint? <ul><li>Scrum doesn’t have&quot; milestones” but things must be done! </li></ul><ul><li>Sprint Planning Meeting (2 to 8 hours): critical to planning your sprint story work </li></ul><ul><li>Daily Scrum Meetings : (15 minutes) A daily chance for the team to sync up </li></ul><ul><li>Completion of Stories within the Sprint : the team works together to complete the stories completely ! </li></ul><ul><li>Functional Demo and Sprint Review: You need to show your completed software to your customers for approval and feedback </li></ul><ul><li>Sprint Retrospective : A mini Lessons Learned, what went wrong, what went right </li></ul><ul><li>Review of the Product Backlog : What has been done, what has to be added from the Sprint Backlog, what are our new priorities? </li></ul><ul><li>Then it starts all over again….. </li></ul>
  27. 27. The Scrum Process How many stories I can complete in the next Sprint? <ul><li>Measure you velocity of the team after the Sprint </li></ul><ul><li>This is easy to measure by looking at the “burn down rate” of the team (by days, story points, etc) </li></ul><ul><li>Now just fill your Sprint with the right amount of stories based on your velocity. </li></ul><ul><li>Remember, the team has to agree to do the work! </li></ul><ul><li>Always plan a few extra stories as “bonus stories” if you have extra time </li></ul><ul><li>The Burn Down </li></ul><ul><li>Work that is completed is track against remaining days of the sprint </li></ul><ul><li>The target line indicates the velocity the team should track to during a sprint </li></ul><ul><li>Points above the line indicate work trending slower, points below the line indicates work trending faster </li></ul><ul><li>As you complete your work you should trend downward to 0 hours of work on the last day of the Sprint </li></ul>
  28. 28. The Scrum Process From Release Planning to the Daily Scrum: A Recap <ul><li>Each team plans, sizes, manages and executes on its Product Backlog </li></ul><ul><li>The Backlog is an ongoing “living” list and needs constant attention </li></ul><ul><li>Value assessment, ROI, and prioritization is key! </li></ul><ul><li>Each Project Starts with High Level Release Planning ( ~3 months out) </li></ul><ul><li>Each Sprint starts with Sprint Planning ( 1 week to 1 month out) </li></ul><ul><li>The team meets in daily scrum meetings (15 minutes sync ups) </li></ul>
  29. 29. The Scrum Process What if the work isn’t a story? <ul><li>Sometimes the work you do on a project won’t really add value to the business and isn’t functional. Examples of this include team training, infrastructure set up, installation of products, etc. </li></ul><ul><li>Scrum uses several different terms and processes to handle these types of scenarios </li></ul><ul><li>Sprint 0: To “setup” a project or product, to do non-functional work </li></ul>
  30. 30. The Scrum Process What if this non-functional work comes during a Sprint? <ul><li>In Scrum you can create stories that are considered Spikes </li></ul><ul><li>Spikes would be tasks in a sprint that aren’t functional and don’t add direct business value </li></ul><ul><li>Spikes should be time boxed, and won’t deliver any real business value </li></ul><ul><li>Depending on how you measure velocity, (by story value points vs. time) this may impact your sprint velocity. </li></ul><ul><li>Spikes would include product training, ordering hardware, installing components, seminars, etc. </li></ul>
  31. 31. The Scrum Process This is fast, how do I continue to do good work? <ul><li>How we do it: </li></ul><ul><li>Requirement are stated as series of tests which allows for Test Driven Development </li></ul><ul><li>Developers can then design and build product to pass tests </li></ul><ul><li>This reduces probability and severity of future defects </li></ul><ul><li>This provides testers opportunity to conduct exploratory testing </li></ul><ul><li>Allows for work to be “sequential” – but all activities occur all the time (Agile) </li></ul><ul><li>We continuously integrate </li></ul><ul><li>We pay close attention to technical details and good code writing </li></ul><ul><li>We keep our technical debt low (time consuming mistakes or assumptions) </li></ul><ul><li>You do not need to finish one type of activity before moving on, which means no bottlenecks  </li></ul><ul><li>In order to embed quality we need a single process flow! </li></ul>
  32. 32. The Scrum Process More on Test Driven Development <ul><li>Automation of Tests and Continuous integration of code is key! </li></ul>
  33. 33. The Scrum Process What else do I need to know? <ul><li>The Team only works on one Sprint at a time </li></ul><ul><li>Once the Sprint is agreed to, the stories cannot change. </li></ul><ul><li>New stories would be vetting against the product backlog and executed in future sprints </li></ul><ul><li>A Sprint should never be extended! You must complete as many stories as possible, and move onto the next sprint, reprioritizing your backlog with the unfinished stories and plan your next sprint </li></ul><ul><li>Focus on completing features and functionality, not tasks! </li></ul><ul><li>There is truly no “I” in a Scrum Team </li></ul><ul><li>Prioritization is key, it’s the Product Owners job to define priority </li></ul><ul><li>It’s the Scrum Masters job to keep everyone working together </li></ul><ul><li>Scrum meetings start on time, and do not move! </li></ul><ul><li>Everyone should attend these meetings </li></ul><ul><li>A Sprint has a Sprint Backlog, this feeds the Product Backlog </li></ul>
  34. 34. The Grocery Analogy
  35. 35. The Grocery Analogy Agile & Scrum happen everyday  <ul><li>You make a list of groceries: “Product Backlog” </li></ul><ul><li>You think about what you want to eat that week, Maybe you will make spaghetti 1 night, hamburgers the next etc: “Stories” </li></ul><ul><li>Your prioritize this list based on your budget, what you need what your family wants to eat, planned dinners for the week:: “Product Backlog Prioritization” </li></ul><ul><li>You don’t try to plan for 6 months of groceries, you maybe plan 1 or 2 weeks in advance: “ Sprint Planning ” </li></ul><ul><li>You finalized your list and head to the store to buy your items: &quot; Completion of Stories” </li></ul><ul><li>You check that you’ve gotten everything on your list and get feedback from your family on your purchases: “ Sprint Review ” </li></ul><ul><li>If your forget something, made a bad dinner, etc. you move the item to next week’s list, or plan on not making that again: “ Re-prioritization and Review of the Backlog ” </li></ul><ul><li>You tell yourself you won’t forget the item next week and write it in bold letters on the list, you never make that “bad” dinner again: “ Sprint Retrospective ” </li></ul>
  36. 36. <Insert Picture Here> Thank You! <ul><li>A majority of this information was taken from the Big Visible CSM training documentation. Big Visible was kind to share and approve the use of this information. </li></ul><ul><li>For more information on Big Visible and their training, see their website: http:// / </li></ul>