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.

Why scrum

1,190 views

Published on

A real life story about project failure & success and how Scrum contributed to the success.

  • Be the first to comment

Why scrum

  1. 1. So why SCRUM? Ciprian Sorlea, Development Manager September 2013
  2. 2. 2 A real life story October 2007, USA October 2007 The Customer had an Idea, and wanted to build a Product.
  3. 3. 3 A real life story November 2007 The Customer has identified the right Consultant to implement his Product.
  4. 4. 4 A real life story May 2008 The Customer and the Consultant have built the Documentation & Requirements, so they should be ready for implementing (by us).
  5. 5. 5 A real life story June 2008 The Development Team evaluated the Requirements and they came up with the Estimates.
  6. 6. 6 A real life story July 2008 The Customer and the Consultant decide to rebuild the requirements: - To be able to cut the cost of development with 30% due to the budget limitations - To be able to accommodate the new market demands + new ideas
  7. 7. 7 A real life story December 2008 The updated requirements are ready. This time, twice as “complete”. It’s time to start re-evaluating the estimates.
  8. 8. 8 A real life story January 2009 With the updated estimates approved, we’re ready to start doing the WORK. It’s only been 16 months since the Customer had the Idea.
  9. 9. 9 A real life story April 2009 The Consultant shows the end result to the Customer. The Customer realizes the mistakes and…
  10. 10. 10 A real life story … fires the Consultant and decides to work directly with the Development Team.
  11. 11. 11 A real life story Summary of phase 1: - Idea to product: 20 months - Customer satisfaction: almost 0% (time wasted, features not how the customer envisioned, etc.). - ROI: almost 0, as the product is already behind the market
  12. 12. 12 A real life story Other problems in phase 1: - Developers had many ideas, but because of the contract & estimates, they had to stick to the requirements - Estimates were highly inaccurate due to the unknown business requirements and some undocumented dependencies, plus all the other issues that “came up” - Developers were frustrated because their product was nowhere to see (can’t brag about to their fellow developers)
  13. 13. 13 A real life story The profit made by the Development Company: 10% of the contract value
  14. 14. 14 A real life story
  15. 15. 15 A real life story In phase 2, we decided to make some slight adjustments to the process
  16. 16. 16 A real life story We started with just enough documentation: - The vision & value proposition - Some mockups - High level description of the features
  17. 17. 17 A real life story We brainstormed with the customer, analyzed all requirements and we put a bunch of ideas on the wall. Including our own ideas. Including some ideas that would never make it into the product.
  18. 18. 18 A real life story The customer then analyzed all important ideas and assigned them a value. A business value. We evaluated the ideas and assigned them a rank, so that we know which are the most complex, and which ones are easy to do.
  19. 19. 19 A real life story We sorted the items on the wall based on their contribution to the ROI (their value) and the complexity. The ones that were easy to do and could bring a lot of value were always first.
  20. 20. 20 A real life story We estimated how much we could do before we could show the result of our work to the customer (2 weeks) and we picked what we’ll deliver at the end of the 2 weeks period, as a team. We had daily short meetings to see if we are on the track with our progress, if anybody has any issues so that the team can step in and help.
  21. 21. 21 A real life story We demoed the completed features to the customer at the end of the period, and collected feedback. We talked after each demo and identified few things that could help us be a better team.
  22. 22. 22 A real life story Every week we removed some of the ideas from the wall, as they didn’t made sense anymore. Or we added new ones. We were happy to change anything on the wall, because we knew it’s making OUR product better
  23. 23. 23 A real life story We continuously expressed our ideas and helped the customer find easier and faster solutions to some of his needs. This helped the customer save money while getting a better product and it helped us to do interesting things.
  24. 24. 24 A real life story And we repeated this several times (about 5 times – so for two months and a half), till the client said: “I’m happy with what I have so far. Everything else that we had on the requirements, I think my customers will never need.”
  25. 25. 25 A real life story Summary of phase 2: - Idea to product: 3 months - Customer satisfaction: 100%. Not only the customer got what he wanted, he got more, for less than the expected investment. - ROI: very high, as the customer started making money from some beta subscriptions since the 3’rd iteration.
  26. 26. 26 A real life story The profit made by the Development Company: 70% of the initial contract value
  27. 27. 27 A real life story
  28. 28. So what are we looking at? Where is SCRUM in this story?
  29. 29. 29 The SCRUM Framework
  30. 30. 30 SCRUM - Roles & Responsibilities - Product Owner: maximizes the business value delivered by the team, by setting the right priorities and defining enough information - Scrum Master: a servant leader who helps everybody follow the process and helps the PO to keep the backlog in good shape. Removes impediments from the team. - The Team: self organize themselves to deliver the WORK in the most efficient way
  31. 31. 31 SCRUM - Artifacts - Product Backlog - Sprint Backlog - Burndown Chart - Product Increment - Impediments Backlog
  32. 32. 32 SCRUM - Product Backlog - A prioritized features list - Anybody can contribute (including stakeholders) - Can only be prioritized by the Product Owner - Priorities can change at any time, depending on the dynamic of the business - Content can be changed at any time - Can contain User Stories, Epics or Themes
  33. 33. 33 SCRUM - User Stories - "As a <role>, I want <goal/desire> so that <benefit>“ - Focused on personas/actors/roles - Must be achievable during a single iteration - Each story must generate value (Business Value): - Return Of Investment: $$$ - Customer Satisfaction: eventually translates into $$$
  34. 34. 34 SCRUM - Epics - More than a story, but not the whole book - Can group multiple stories that are part of the same feature - Can group multiple stories that represent the functionalities split among various roles or actors of the system - Can group multiple stories that belong to the same feature across various components - Represents the mid term plans, and will require further details, clarifications and breakdown
  35. 35. 35 SCRUM - Themes - Represents Long term plans - Will eventually be broken down into related stories and or epics
  36. 36. 36 SCRUM - Backlog prioritization - Each story should have a Business Value assigned - Each story should have an estimate (Story Point) - Both estimates could be made using planning poker - The R factor (BV/SP) allows accurate prioritization
  37. 37. 37 SCRUM - Story Point - An arbitrary measure of complexity for Stories, meant to be used as a scale for comparing stories (comparing all stories to a baseline) - Can use Tshirt Sizing (XS, S, M, L, XL) - Can use the Fibonacci sequence (1,2,3,5,8,13, etc) - Usually established through poker planning - Stimulates the communication and collaboration to reveal facts and details about stories
  38. 38. 38 SCRUM - Sprint Backlog - A list of refined and detailed enough user stories - All stories picked should be Ready Ready - Picked by the team to be implemented during the sprint - It reflects the team forecast and commitment towards what will be completed - It’s still sorted based on PO set priorities. - The team can help the PO to adjust the priorities to reflect some dependencies between stories
  39. 39. 39 SCRUM - Burndown Chart
  40. 40. 40 SCRUM - Burndown Chart - A visual representation of the progress of the team towards the completion of the work in the sprint - Can be used to predict the completion or to identify the bottlenecks as they occur - Should be updated real time (when tasks are completed, or when a new evaluation is available - remaining effort) - Can be based on hours (tasks), number of tasks or number of stories remaining - Focus is on remaining effort needed to get all things done
  41. 41. 41 SCRUM - Product increment - It’s the outcome of the team’s work during the sprint - Contains all the demoed and PO accepted user stories - All stories within the increment must be Done-Done - Should constantly deliver Business Value - It should be Production Ready
  42. 42. 42 SCRUM - Impediments Backlog - A list of issues that prevents the Team to perform as they would want to - The list is based on the feedback from the Team - It is prioritized by the team - It has action items associated - The Scrum Master collects the backlog - The Scrum Master follows up with the responsible of each action item
  43. 43. 43 SCRUM - Activities
  44. 44. 44 SCRUM - Other Activities - Product Planning - Release Planning - Backlog Grooming - Mid Sprint Review - Detailed Sprint Planning / Task Breakdown
  45. 45. 45 SCRUM - Ready Ready - Defines the level of information needed for each story before they are considered ready for development - Ex: - Contains the mockups - Defines the acceptance criteria - Defines the non functional requirements (security, performance, etc) - Might be different depending on story/issue type (ex. defect, escalation, etc)
  46. 46. 46 SCRUM - Definition of Done - Defines when the story is Done Done (aka ready for production and PO acceptance) - Contains what the Team along with PO expect and commit to deliver with each story - Ex: - Documentation - Code Review - Unit tests passed - QA Acceptance - Continuous Integration - End To End Integration passed - Performance tests - Demo Scripts & Recorded Demos
  47. 47. So how do we get SCRUM to work for us?
  48. 48. 48 The SCRUM Principles
  49. 49. 49 The Agile Manifesto ○ Individuals and interactions over processes and tools ○ Working software over comprehensive documentation ○ Customer collaboration over contract negotiation ○ Responding to change over following a plan
  50. 50. 50 The SCRUM values ○ FOCUS ○ COURAGE ○ OPENESS ○ COMMITMENT ○ RESPECT
  51. 51. 51 To make it work ○ Let SCRUM do its work ○ Understand the core framework before trying to change it / adapt it ○ Follow the principles ○ Respect the values ○ Don’t try shortcuts (SCRUMBUT)
  52. 52. 52 To make it work ○ Work as A TEAM
  53. 53. Thanks for watching. Now go have some fun, with SCRUM!

×