Successfully reported this slideshow.



Published on

An intro to Agile/SCRUM give at Charlotte User Experience Group by Scott Inman of Cardinal Solutions.

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


  2. 2. How effective are your current processes and practices? Not Very 1 2 3 4 5 6 7 8 9 10
  3. 3. How familiar are you with Scrum? Not Very 1 2 3 4 5 6 7 8 9 10
  4. 4. 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 7 8 9 10 ScrumFamiliarity Current Process Effectiveness Living the dream Things are just fine without Scrum Learning and improving We know what to do, and we aren’t doing it This hurts. Help. Where are you located on this graph?
  5. 5. TRUTHS ABOUT TEAM MOTIVATION • People are most productive when they manage themselves • People take their commitments more seriously than other people’s commitments for them
  6. 6. TRUTHS ABOUT TEAM PERFORMANCE • Teams and people do their best work when they aren’t interrupted • Teams improve most when they solve their own problems • Face to Face communication is the most productive way for teams to work together • Teams are more productive than the same number of individuals
  7. 7. Scrum in a Nutshell Product Owner Scrum MasterDevelopment Team Product Backlog Sprint Backlog Daily Scrum Increment Scrum Team Sprint Sprint Planning Sprint Review Sprint Retrospective
  8. 8. SCRUM: ORIGINATION • The term Scrum is borrowed from a rugby play where everyone stays focused on the ball • A way to restart the game when the ball has gone out of play • Players connect together as a team to compete for the ball
  9. 9. SCRUM: THE FRAMEWORK • Scrum is not a methodology • Scrum is a tool used to create agility • A framework within which people can address complex problems and deliver products of the highest possible value
  10. 10. Progress = Value Delivered (not effort expended) Value = Potentially Deployable Software • Requirements 90% Complete doesn’t deliver value • Design 20% Complete doesn’t deliver value The sole measure of progress is “Potentially Deployable Software” DELIVERING VALUE
  11. 11. MANAGEMENT NO LONGER NEEDS TO… • Make commitments on behalf of the team • Give direction to the team on how to meet commitments • Monitor teams progress to keep it on schedule • Step in and fix problems if encountered • Push team to work harder • Decide work assignments and follow up to ensure they are done
  12. 12. SCRUM LIFECYCLE PLAN ANALYZE DESIGN CODE TEST RELEASEWaterfall: Scrum: P L A N ANALYZE DESIGN CODE TEST RELEASE R E V I E W The same work, but organized differently and on fewer requirements, Waste becomes visible and can be quickly removed Short, high value iterations that deliver functionality
  13. 13. Scrum Team Roles Product Owner Development Team Scrum Master Service flows this way
  14. 14. PRODUCT OWNER • Maximizes the Return on Investment • Creates and orders Product Backlog • Chooses what and when to release • Single voice of the Customer • Represents interests of stakeholders and customers
  15. 15. PRODUCT BACKLOG • A prioritized and complete list of desirements • Potential features of the product • Managed and groomed by Product Owner • 10% of each sprint is spent discussing and analyzing the backlog • Single source of truth for what is planned for the product • Public and available
  16. 16. PRODUCT BACKLOG ITEM • A unit of deliverable work • Contains clear acceptance criteria (criteria for successful completion) • May reference other artifacts like Specifications, Use Cases, Wireframes, etc. • Must be sized appropriately • Small enough to be completed within a single Sprint
  17. 17. • PBIs are estimated and ordered for about 3 Sprints at all times • The current sprint is detailed  Broken into tasks  Very granular detail • PBI’s for next 2 sprints are groomed  Understood by the entire team  Ordered  Estimated  User Stories with acceptance criteria Current Sprint Next Sprint Next, Next Sprint ROLLING PRODUCT BACKLOG PROJECTION
  18. 18. USER STORIES – COMMON EXPRESSION OF PBIs • High level desires of your product backlog are incrementally decomposed into Detailed requirements in the form of User Stories with Acceptance Criteria
  19. 19. WHAT IS A USER STORY? • Represents the basic unit of work for a Scrum team • Cross-functional team members hold conversations to flush out the detailed requirements User Stories contain two main components: 1. Value Story: As a <Role> I Need <Goal> So That <Reason> 2. Acceptance Criteria: Detailed requirements (Functional, Non-Functional, Data, etc)
  20. 20. USER STORY EXAMPLE Value Story: As an online banking customer, I need the Overview page in a 1024 x 768 screen resolution so that I can view more information on the page. Acceptance Criteria: Given a PC that has the screen resolution set at 1024 x 768: 1. Customer sees the screen without any horizontal scroll bar 2. Customer sees the honeycomb background on the right and left side of the page 3. Customer sees the page centered in the browser
  21. 21. THE DEVELOPMENT TEAM • Cross-functional • Jointly owns and commits to product backlog items • Ideally collocated, dedicated resources • 6 members, +/- 3 (recommended not required) • Highly collaborative • Empowered and self-managed • Everyone pitches in regardless of individual skill or specialty • Held accountable as a Unit
  22. 22. The Development Team should have every competency it needs to deliver an increment of “done” functionality THE DEVELOPMENT TEAM
  23. 23. ESTIMATING • Relative estimates are assigned to Product Backlog items • Fibonacci Set of Numbers (1,2,3,5,8,13 or 21) • Medium size effort is 8 • Team votes on the relative size of the effort to do the product backlog item  Discuss if large discrepancies in voting occur  If close, use the higher number • Do not count on estimates by people who will not be doing the work
  24. 24. FOUNDATION OF SCRUM We all know what Is going on. Check your work as you do it. OK to change tactical direction.
  25. 25. EMPIRICAL PROCESS • Knowledge comes through experience • Just in time planning and re-planning based on frequent inspection • Based on actuals rather than predictions • Requires transparency • Information is neither good nor bad only used to make decisions • Does not try to predict the future, only adapts to the current Scrum makes everything Transparent all the time so that they can be quickly fixed
  26. 26. EMPIRICAL PROCESSES PLAN FREQUENTLY P DPlanning Doing Predictive Empirical • All planning is done at beginning • Just-in-time planning and re- planning based on frequent inspection P D P D P D P D P D
  27. 27. SPRINT • Time-boxed at 30 days • Contains the work necessary for the increment of functionality and other events • Functionality is potentially shippable • Consistent durations • Conducted in a vacuum, team is totally protected from outside noise and interference
  28. 28. SPRINT PLANNING • Time-boxed at 8 hours for 4 week sprints, proportionately less for shorter Sprints • Product Owner reviews top priority items with Development Team • Development Team determines how much they can do and tasks necessary to complete items (Sprint Backlog) • Sprint Goal is created
  29. 29. SPRINT GOALS An objective to be met in the Sprint Allows flexibility in delivering the increment of functionality No changes may affect the Sprint goal during the Sprint As team works, this goal is kept in mind Each Daily Scrum assess the teams progress towards the goal
  30. 30. DEFINITION OF DONE • Should include all steps necessary to make that PBI potentially shippable • Adhere to “done” every Sprint • “Done” is for the entire product not just for one scrum team’s increment • All Scrum teams working on a product must have the same definition of done • Should be inspected at the end of each sprint • Must be transparent
  31. 31. DONE MIGHT INCLUDE… • Performance Testing • Code Refactoring • Integration with other teams (syncing, integration of code, etc.) • Release notes • User Acceptance testing • Regression testing • Code reviews
  32. 32. INS and OUTS of SPRINT PLANNING INPUTS OUTPUTS • The Product Backlog • The latest increment • The number of hours the Development Team has available to work (Capacity) • Past performance of the development team (Velocity) • Definition of Done • The Sprint Goal • Sprint Backlog • 60% - 70% known and accurate • Some work emerges later
  33. 33. SPRINT BACKLOG • Created by Development Team during Sprint Planning • Includes PBI’s committed to and tasks necessary to complete each PBI selected • Each task must be granular enough to be completed in 1 day or less • Development team members sign up for tasks, they aren't assigned • Any development team member can add, delete or change the Sprint backlog • Work for Sprint emerges over time • If work is unclear, update work remaining as more is known and tasks are worked
  34. 34. CREATING THE SPRINT BACKLOG Team selects a PBI based on product backlog order Team identifies all tasks necessary to complete PBI Team estimates PBI via Story Points Add PBI to Sprint Backlog Negotiate what can be delivered from PBI or place item back in Product Backlog Does PBI fit into Sprint? YES NO
  35. 35. SPRINT AS A “DEAL” The Development Team Clients “Every Sprint you can have us develop something new as you see fit” FLEXIBILITY “We will leave you alone for two weeks (or more) and will not interfere while you work.” STABILITY
  36. 36. SPRINT TASK BOARD • A way to track the tasks necessary to complete PBI’s • Can be in a scrum room (physical, manual tracking), can be virtual or both
  37. 37. The development team has decided how much it can accomplish during the upcoming sprint. It now sprints to accomplish the sprint goal as it sees fit, adapting to the circumstances, technology and organizational terrain as best it can
  38. 38. SPRINT REVIEW • Time-boxed at 4 hours for 4 week sprints; proportionately less for shorter Sprints • Team demonstrates the increment of functionality • Stakeholders provide feedback • Product Increment and Product Backlog are inspected and adapted • Discuss what can be worked on next
  39. 39. SPRINT RETROSPECTIVE • Time-boxed at 3 hours for 4 week sprints; proportionately less for shorter Sprints • Opportunity for Scrum team to inspect & adapt their development process, tools and definition of done • Develop plan for actionable improvements (to be implemented in next Sprint)
  40. 40. EMPIRICAL PROCESSES REQUIRE COURAGE Conversation will not take place unless people feel safe! Goal realization Crucial Conversation Transparency Inspection & Adaptation
  41. 41. INCREMENT • Working functionality • Is potentially shippable and usable by customer • An output of the Sprint • Must be DONE with no work remaining
  42. 42. SCRUM MASTER • A servant leader • Educates the Product Owner on their role • Ensures the Scrum framework is followed • Facilitates time boxed events • Empowers team to self-organize • Removes impediments
  43. 43. SCRUM MASTER May Be May Not Be • Anyone with the appropriate servant-leader skills • A member of the Development team • Fired by the team • A Product Owner • This is a direct conflict of interest
  44. 44. Executives Managers Anyone on another team Scrum Master Product Owner Development Team Chicken Pigs THE CHICKEN AND THE PIG
  45. 45. DAILY SCRUM • Time-boxed at 15 minutes • Development Team is required to attend • NOT a status meeting, team creates a plan for the next 24 hours • Three questions: 1. What have you accomplished? 2. What do you plan to accomplish? 3. What is impeding or slowing your progress? How will the Development team achieve its forecast based on the inspection?
  46. 46. BURNDOWN CHARTS • Measurement for the Development team • Used to see how they are progressing towards the goal in the sprint • May change abruptly when  New SBIs are added or removed during the Sprint  Scope is renegotiated with the Product Owner • Burndown charts can also be used by the Product Owner to see how they are progressing towards the release
  47. 47. 0 10 20 30 40 50 60 Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10 Work Remaining SPRINT BURNDOWN CHART
  48. 48. VELOCITY • A measure of delivered value per sprint • Used by the Product Owner to provide forecasts • Used by the Development Team to gauge how much work to pull into the Sprint
  49. 49. VELOCITY FROM THE LAST RELEASE 0 5 10 15 20 25 30 35 40 45 50 1 2 3 4 5 6 7 Sprints Velocity = 37 SP’s per sprint Last Sprint = 47
  50. 50. SELF MANAGING TEAMS • Who does what & when • Who is needed on the team and not • What customer input is needed and when • When it needs help resolving Impediments • What process improvements are needed The Team Determines…
  51. 51. FEWER SPECIALISTS • In a multi-disciplinary team of appropriate size, specialization is simply not possible • Task pairing and sharing grows everyone on the team • Team members focus shifts from fulfillment of their own duties to the overall success of the team
  52. 52. ARE YOU THE RIGHT SCRUM MASTER? • Good Scrum Masters are fit via temperament and facilitation skills NOT job title • Good Scrum Masters are ferocious advocates for their teams
  53. 53. WORKING WITH DEPENDENCIES • Prioritization of the Product Backlog should be used to synchronize dependencies • When there are multiple scrum teams working on 1 product, all teams must have a shared definition of done • Work should not be considered done until it is integrated and tested
  54. 54. ROLES, ARTIFACTS, & EVENTS ROLES ARTIFACTS • Product Owner • Scrum Master • The Development Team • Increment • Product Backlog • Sprint Backlog EVENTS • Sprint • Sprint Planning • Daily Scrum • Sprint Review • Sprint Retrospective
  55. 55. CARDINAL AGILE TRAINING Delivery Partner of:
  56. 56. • Next Agile Leadership Series: The Definition of Done: August 1, 2013 • Professional Scrum Foundations Course: August 15-16 in Charlotte! • A successful Agile implementation begins with comprehensive training Contact us to register for our Scrum training today! Contact Information Jim Milam/ Nick Bourdon/ Matt Brookshire 210 East Trade Street Suite C-440 Charlotte, NC 28202 (704) 936-4444 Cardinal Solutions Group