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.

Agile and Scrum Overview for PMs, Designers and Developers


Published on

This is an overview of the flavor of agile/scrum I had my team use at Bond in Q2 2017. We heavily emphasized the importance of having a shared language between cross-functional teams and this deck was meant as a primer that could be shared between product managers, designers, and developers.

Published in: Technology
  • Be the first to comment

Agile and Scrum Overview for PMs, Designers and Developers

  1. 1. Scrum at Bond - Q2 2017
  2. 2. Today we are going to cover... ● Agile/Scrum Overview ● Sprint planning
  3. 3. Why are you seeing this? ● Share our standard and best practices ● Give everyone a chance to ask questions and align
  4. 4. What are the benefits? ● Improve our overall quality of work ● Better communication between product and engineering teams
  5. 5. Agile Overview
  6. 6. In this section we will cover: ● What is Agile software development ● The Agile Manifesto
  7. 7. What is Agile? Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self- organizing cross-functional teams.
  8. 8. What does this mean? Agile frameworks embody incremental, iterative delivery (“Fail fast and learn”) of software instead of all at once.
  9. 9. The Agile Manifesto
  10. 10. Rule 1: Individuals and interactions over processes and tools. The most efficient and effective method of conveying information to and within a development team is face- to-face conversation.
  11. 11. Rule 2: Working software over comprehensive documentation. Working software is the primary measure of progress.
  12. 12. Rule 3: Customer collaboration over contract negotiation. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  13. 13. Rule 4: Responding to change over following a plan. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  14. 14. Agile is NOT waterfall With agile development we do not spec the entirety of a system, built it all, and only then put it in hands of end users.
  15. 15. Types of Agile methodologies ● Scrum ● Kanban
  16. 16. Questions on Agile?
  17. 17. Scrum Overview
  18. 18. Not this type of Scrum
  19. 19. In this section we will cover: ● What is Scrum ● What are Sprints ● Scrum Roles ● Scrum Activities
  20. 20. We use Scrum for agile development at Bond
  21. 21. What is Scrum? Scrum is an agile framework for building products in a series of fixed-length iterations (Sprints).
  22. 22. Scrum is not just a fancy acronym Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  23. 23. What is a “Sprint”? ● In Scrum, teams forecast to complete a set of issues during a fixed time duration, known as a sprint ● Sprints are timeboxed in that they have a fixed start date and end date ○ Generally sprints are two, three or four weeks long ○ At Bond a typical sprint is two weeks in length
  24. 24. Scrum Roles Scrum development efforts consist of one or more Scrum teams, each made up of three Scrum roles: Product owner, ScrumMaster (Delivery Manager), and the Development team.
  25. 25. Product Owner Master note taker and backlog champion ● Accountable for the product ● Owns and prioritizes the Product Backlog ● Provides goals and vision ● Understands the market, users and the business in order to make sound decisions
  26. 26. Key Term - Product Backlog Using Scrum we always do the most valuable work first! Product owner’s (with input from the rest of the Scrum team and stakeholders) are responsible for determining and managing the sequence of work. This prioritized list is known as the product backlog.
  27. 27. ScrumMaster (Delivery Manager) Master tasker, knows how to get stuff delivered ● Works with the Product Owner to define the roadmap for any given product and translate this into user stories ● Enforces process ● Prevents and remove impediments ● Tracks metrics ● Facilitates Daily Scrum
  28. 28. Development Team Builders of high-quality, working software. ● Self-organizes to determine the best way to accomplish the goal set out by the product owner ● Creates their own tasks ● Pulls stories from the Product Backlog ● Owns the sprint backlog ● Provides estimates and commitments
  29. 29. Scrum Activities
  30. 30. Scrum activities at Bond 1. Daily stand-up 2. Sprint planning 3. Sprint review 4. Retrospective
  31. 31. Questions on Scrum?
  32. 32. Daily Stand-up
  33. 33. In this section we will cover: ● Overview of daily standup ● Format ● Best practices
  34. 34. What is the daily stand-up? Meetings are typically held in the same location and at the same time each day. Ideally, a daily scrum meeting is held in the morning, as it helps set the context for the coming day's work. These scrum meetings are strictly time-boxed to 15 minutes. This keeps the discussion brisk but relevant. How we relentlessly prioritize the day’s work
  35. 35. Daily stand-up - format All team members are required to attend scrum meetings. Each team member answers the following three questions: 1. What did you do yesterday? 2. What will you do today? 3. Are there any impediments in your way?
  36. 36. Daily stand-up - best practices ● The daily stand-up meeting is not used as a problem-solving or issue resolution meeting. ○ Issues that are raised are taken offline and usually dealt with by the relevant subgroup immediately after the meeting. ● Any impediments that are raised in the scrum meeting become the delivery manager’s responsibility to resolve as quickly as possible.
  37. 37. Sprint Planning
  38. 38. In this section we will cover: ● Overview of sprint planning ● What is “Ready” for work ● Acceptance criteria ● Story points ● Planning poker ● Velocity
  39. 39. What is Sprint planning? During the sprint planning meeting, the product owner describes the highest priority features to the team. The team asks enough questions that they can turn a high-level user story of the product backlog into the more detailed tasks of the sprint backlog. Defining the "What" and "How" the Scrum team will deliver
  40. 40. Sprint planning - general rules ● Attended by the product owner, scrum master, and scrum team for the upcoming sprint ○ In addition to development team, could potentially include design/UX resources ● Held for 1-2 hours at the beginning of a sprint ● Important to book a conference room and allot proper time (1 hour for every week of sprint to plan)
  41. 41. Purpose of sprint planning Sets up the entire team for success throughout the sprint. During sprint planning we define: 1. The sprint goal 2. The sprint backlog
  42. 42. Key Term - Sprint Goal A sprint goal is a short, one- or two-sentence, description of what the team plans to achieve during the sprint. It is written collaboratively by the team and the product owner.
  43. 43. Key Term - Sprint Backlog The sprint backlog is a list of the product backlog items the team commits to delivering plus the list of tasks necessary to delivering those product backlog items. It’s the product owner’s job to make sure all items being discussed are “ready”.
  44. 44. What makes a backlog item “Ready”? "Ready" items should be clear, concise, and most importantly, actionable. ● "Ready" means that stories must be immediately actionable ● The Team must be able to determine what needs to be done and the amount of work required to complete the backlog item ● The Team must understand the acceptance criteria and what tests will be performed to demonstrate that the story is complete
  45. 45. Acceptance Criteria (A/C) Sets clear expectation as to when a team should consider something done. ● Product owners are responsible for creating A/C and validating whether work is complete ● It helps the team to break down the user stories into task(s) ● Unique for each backlog item ● A ticket without criteria, should not be considered "ready"
  46. 46. Bond format for A/C I will consider this done when… ● -Action a yields x result ● -Action b yields y result ● -Action c yields z result Typically there should be at least 4, no more than 12 actions described.
  47. 47. A/C differs from the “Definition of Done” A/C is unique to every backlog item. The Definition of Done (DoD) is a clear and concise list of requirements that the user story must satisfy for the team to call it complete. The DoD must apply to all items in the backlog.
  48. 48. Definition of done at Bond Examples at Bond: ● Passed QA and code review ● Unit test written ● Seen by and approved by the Product Owner
  49. 49. Acceptance Criteria Examples
  50. 50. The Good “As a Bond employee, I want a dropdown from live search with corresponding fields.”
  51. 51. Why is that a “good” example? ● Clear A/C with fringe rules outlined for the feature ● Expectation for how feature should behave once user interacts ● Limits for how feature should be implemented are clear ● Visual or prototype attached to the ticket
  52. 52. The Bad “As a Bond employee, I want to create an invoice for a user.”
  53. 53. Why is that a “bad” example? ● Overly complex for a single item, thus A/C is more work then could be completed in a single sprint ○ This should have been split into multiple tickets ○ Every single editable field could have been individual ticket ● Specific visual spec is not attached to ticket ● Not all work is actionable at moment
  54. 54. The Ugly “As a Bond employee, I want to see success or failure on my interactions with Skyfall.”
  55. 55. Exercise Break
  56. 56. Draw me a house
  57. 57. Draw me a house I will consider this done when: ● There is a door on the lower floor in the middle of the house ● On each side of the door there is a window ● On the upper floor, there are three windows evenly spaced across the house ● The house has a pitched roof. ● There is a chimney ● The house has a garage ● The house has a fence around a garden ● The fence has a gate ● There is a path from the door of the house to the gate ● The garden has a tree
  58. 58. Questions on sprint planning, definition of “ready”, or acceptance criteria?
  59. 59. Story points and estimation Now that our backlog item’s are ready it’s time to estimate story points. Story points are a measure of the relative size of a backlog item, taking into account factors such as complexity and physical size.
  60. 60. We use planning poker for estimation ● The goal of planning poker is to gather consensus among team members ● The work we agree to do, is the work we agree to complete
  61. 61. How planning poker works 1. The product owner describes each item to the team before they estimate it 2. Product owner answers questions regarding functionality to make sure end goal is clear 3. Any member of team who will be contributing to completion votes with planning poker card 4. The majority wins the vote, but for huge discrepancies this is a good time to have dialogue so any potential unforeseen issues are brought up.
  62. 62. Guidelines for story points ● Issue that is understood and can be done and deployed in under an hour ≤ 3 ● Issue requiring a bit of understanding but can be done in a few hours = 5 ● Issue requiring research and thought before implementation = 8 ● Issue requiring potentially multiple days and efforts to accomplish = 13 ○ Max hours for a 13 point ticket = 16 hours
  63. 63. How much is too much? Using “Velocity” to predict a team’s capacity for work. At the end of each iteration (sprint), the team adds up effort estimates associated with user stories that were completed during that iteration. This total is called velocity. Past velocity is a great indicator for how many story points to include in a sprint.
  64. 64. Planned vs. actual velocity Planned velocity is the total number of story points that the team has committed to for the sprint. Actual velocity is the total number of story points the team completes during the sprint.
  65. 65. Expect the unexpected It’s the product owner’s role to prevent the the team from over-committing. Other factors that influence velocity: ● Holidays ● Time off for members of team ● Internet/heat outages
  66. 66. Time-boxing sprints is absolutely critical The fixed start and end dates are a commitment between team members that you will take on and complete X amount of work, and in the allotted period of time. If we allow sprints to run past the timebox it ruins the ability to accurately predict the future amount of work a team can accomplish (velocity).
  67. 67. What happens when you don’t timebox?
  68. 68. The perils of not time-boxing ● The 200 point sprint was only possible because we did not adhere to the timebox rules ● We began enforcing timeboxed sprints and at first it was ugly. A sprint with only half the points completed ● With timeboxing, preparation is much more thorough before starting work, thus what we “commit to complete,” we expect to deliver
  69. 69. Format for Sprints at Bond How to use Jira for planning and starting sprints. ● Sprint Goal ● Sprint Name ○ Year/Month/Date started ○ This makes it easy to look at prior sprints
  70. 70. What have we learned today? ● What is agile development ○ The agile manifesto ● What is Scrum ○ Roles and activities ● Daily stand-up ● Sprint planning ○ How to plan and start a sprint ○ What is “Ready” for work ○ Acceptance criteria ○ Story points ○ Planning poker ○ Velocity
  71. 71. Questions?
  72. 72. Further resources ● Daily stand-ups ● Sprint planning ● Sprint reviews ● Sprint retrospective ● Jira agile guidelines