Agile Development with Scrum.pptx

1. AGILE DEVELOPMENT WITH SCRUM 9/13/2012

2. Checkpoint  Foundations of Scrum  High Level Scrum Overview  Roles in Scrum  Sprints and the Definition of Done  Agile Engineering Techniques  Agile Requirements with User Stories  Agile Estimating  Release Planning and tracking

3. Official Scrum Definition A development framework wherein cross functional, self managing teams deliver working software every thirty days.

4. Unofficial ‘Zen of Scrum’  Hire Smart People  Put them in small cross functional teams  Trust & empower those teams  Ask them to demonstrate working stuff once a month

5.  What should we build?  Watt’s Humphries: “Requirements cannot be fully known until users have tried the software.”1  Jakob Nielsen: “For 50 years, almost all experience with traditional waterfall development methods have found that it results in poor user experience. The reason is simple: requirement specifications are always wrong.” 2 1Watts Humphrey's Requirements Uncertainty Principle 2Agile Usability: Best Practices for User Experience on Agile Development projects Why Scrum?

6.  Simple, Definable Projects:  Given a set of inputs, tasks can be defined that will generate the same outputs every time.  Complex, Chaotic Projects  Tasks cannot be defined that will generate consistent outputs  Axes of Certainty  Technical and Domain are only two…  Team stability, capability  Organizational agreement on priority 6 Technical Certainty High Low High Low Domain Certainty Simple Complex Chaotic Anarchic Complex Why Scrum?

7.  Defined (predictable) projects  Define, Estimate, Create a Plan, and Execute to Plan  Empirical (chaotic) projects  Define Small Portion, Estimate, Create a Plan, Execute 7 Why Scrum?

8.  Defined (predictable) projects  Define, Estimate, Create a Plan, and Execute to Plan  Empirical (chaotic) projects  Define Small Portion, Estimate, Create a Plan, Execute  Inspect & Adapt Plan  Create Plan & Execute 8 Why Scrum?

9.  Defined (predictable) projects  Define, Estimate, Create a Plan, and Execute to Plan  Empirical (chaotic) projects  Define Small Portion, Estimate, Create a Plan, Execute  Inspect & Adapt Plan  Create Plan & Execute  Inspect & Adapt Plan  Create Plan & Execute  Inspect & Adapt Plan  Create Plan & Execute  Inspect & Adapt Plan  Create Plan & Execute… Why Scrum?

11. What Scrum is and what it is not: Scrum Is Not: Scrum Is: A development methodology that will make us build software faster A tool that will help us discover things we can do to build software faster

12. What Scrum is and what it is not: Scrum Is Not: Scrum Is: A development methodology that will make us build software faster A tool that will help us discover things we can do to build software faster A solution to development problems Something that exposes development problems early and often

13. Agile Manifesto (2001)  A set of values: Over Over Over Over Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith,

14. Product Backlog Sprint Backlog Daily 2-4 Weeks Potentially Releasable Increment Sprint Goal Scrum Overview The list of all desired work for a product, project, or team Prioritized (1-n) by the Product Owner to ensure:  Balanced stakeholder demands  Alignment to corporate strategy  Driving of profit engine Can be added to by anyone Ideally expressed such that each item has value to the users or customers of the product Frequently updated Potentially Releasable: 1. Delivers some value to users 2. High enough quality to release Vertical Slices:

16. Three Roles in scrum  Product Owner  Scrum master  Scrum Team

17. Three Roles in scrum: Product Owner  Product Owner  Defines the features of the product, decides on release date and content  Is responsible for the profitability of the product (ROI)  Prioritizes features according to market value  Can change features and priority every sprint  Owns the “What to build” decisions

18. The 3 responsibilities of a Product Owner 1. Inspire The Team with your vision of what the product can become  Keep team focused on the Big Picture things like:  Target users, personas  Market opportunities  Long term strategy & roadmaps 2. Build The Product Backlog  Manage all stakeholder requests in a single, frequently update list  Present a clear, visible record of the product’s current priorities  Decompose large user problems into smaller ones as they approach implementation 3. Provide Feedback to the team:  You represent the users  Provide ongoing feedback during sprints and at sprint reviews

19. Three Roles in scrum: Scrum Master  Scrum master (1 per scrum team, initially)  Responsible for enforcing the values and practices of the process and the team  Remove impediments from the team  Remove barriers between team and others  Educate outside groups about how the team is working  Improve productivity in any way possible  Shields the team from external interferences  Owns the “Scrum Process” decisions

20. Three Roles in scrum: Scrum Team  Scrum Team  No formal concept of “Eng vs. QE”, only team members with individual expertise  7 developers, +/- 2 make up a scrum team  Scale through having multiple scrum teams  Selects the sprint backlog  Has the right to do everything within the boundaries of the project guidelines to reach the iteration goal  Organizes itself and its work  Demos work results to the Product Owner  Owns the “How to build” decisions (including how fast)

21.  There are two main ways to structure teams:  Based on Architectural Layers  Cross-functionally Cross Functional vs. Architectural Layers Lead Architect Backend Programmer Backend Programmer Backend Programmer Backend Programmer Tester Tester Backend Team Frontend Team UX Designer Frontend Programmer Tester Tester Frontend Programmer Frontend Programmer Generalist Programmer Tester Lead Architect Backend Programmer Backend Programmer Backend Programmer Backend Programmer Tester Tester Cross Functional Scrum Team 1 UX Designer Frontend Programmer Tester Tester Frontend Programmer Frontend Programmer Generalist Programmer Tester Cross Functional Scrum Team 2

22. Overview of roles Product Owner Scrum Master Scrum Team What will we make? 1 per team or backlog Prioritize the Backlog  Provide Vision  Answer team’s questions  Work with all customers  Manage stakeholders Is the team healthy? Following the rules?  Ideally 1 per scrum team Team functioning highly  Team protected within sprints  Information team needs is readily available The oil that keeps the team running. How will we make it? How Fast?  ~7 people per team  Creative engineering solutions to customer problems  Architecture  Code Quality  Sprint Backlog  Commitments for the sprint

23. Working on product backlog Role Time spent on sprint Time spent on Product Backlog Product Owner 10-20% 80-90% Scrum Team member 90% 10% UX, Architect, etc. 50% 50%  Product Owner  Prioritize the backlog items  Work with stakeholders to add new items as they are requested  Ensure that high priority items are being decomposed to an appropriate size  Scrum Team  Provide estimates  Provide technical backlog items necessary to reach product vision  Help the P.O. decompose items

24. Checkpoint  Foundations of Scrum  High Level Scrum Overview  Roles in Scrum  Sprints and the Definition of Done  Agile Engineering Techniques  Agile Requirements with User Stories  Agile Estimating  Release Planning and tracking  Debrief

25. Sprints  Two to four week iteration  Deliver working software  Deadline is sacred  Drop scope to meet the deadline  Product Owner can’t add new stuff once they’ve started  Team Can  Product Owner can abnormally terminate

26. Scrum Meetings Sprint Planning Meeting Daily Scrum Meeting Sprint Review Meeting Sprint Retrospectiv e Meeting Scrum of Scrums Meeting

27. Purpose of sprint planning  What is the primary goal of the sprint planning meeting? Sprint Planning Meeting Daily Scrum Meeting Sprint Review Meeting Sprint Retrospectiv e Meeting

28. Purpose of sprint planning  Arrive at a commitment to a sprint goal or set of product backlog items  Not “come up with a list of tasks”  Tasks and estimates are a tool to ensure we can commit Sprint Planning Meeting Daily Scrum Meeting Sprint Review Meeting Sprint Retrospectiv e Meeting

29. Sprint Planning  Day 1 of sprint  Sometimes broken into two parts:  Part 1 (4 hours):  Product Owner describes user stories  Clarifying discussion with the team  Sprint Goal is chosen  Initial Commitment from team  Part 2 (4 hours): Determine Capacity for sprint Break down stories into tasks (code, test, etc.)  Estimate tasks in hrs or days (1/2–2 days)  Final commitment for sprint  These two can be combined:  Discuss first backlog item,  Break it down into tasks  Task estimates  Team commits  Repeat with item 2 Product Backlog Sprint 1 Sprint 2 Sprint 3 Sprints 4-5 Sprints 6-10

30. Breakdown a story/feature into tasks Product Backlog Sprint Backlog At the end of the sprint planning meeting you have:  a set of estimated tasks  a team commitment to complete the product backlog items represented by the sprint backlog Sprint Planning Meeting Daily Scrum Meeting Sprint Review Meeting Sprint Retrospectiv e Meeting

31. Sprint Burndown Chart 1 0 9 8 7 6 5 4 3 2 1 0 50 40 30 20 10 0 Y: Stuff Left To Do: X: Time Left in Sprint:

32. What if we discover we’re over- committed?  Two options (team chooses): 0 200 400 600 800 1000 1200 1400 28 26 24 22 20 18 16 14 12 10 8 6 4 2 0  Work overtime to meet the commitment  But: sustainable pace?  Remove work as soon as they think they’re over committed  This is a discussion with the product owner.

33. Daily Scrums 15 Minutes  Three Questions What have you done? What will you do? What’s in your way?  Goal 1: commit in front of peers.  Goal 2: ensure we’re on track to meet our commitments for the sprint.  Not for problem solving Sprint Planning Meeting Daily Scrum Meeting Sprint Review Meeting Sprint Retrospectiv e Meeting

34. Scrum of Scrums  Each team sends a representative  Rotate attendance based on whose skills are needed most  Usually 2-3 times per week  Four Questions What has your team done? What will your team do? What’s in your team’s way? What are you about to put in another team’s way?  These are problem solving meetings Sprint Planning Meeting Daily Scrum Meeting Sprint Review Meeting Sprint Retrospectiv e Meeting Scrum of Scrums Meeting

35. Definition of Done  General Definition of Done: the template of development steps that all features should go through, determined by the team and the product owner at the beginning of the cycle.  Typically includes things like:  designed, coded, automated tests created, unit tests created, functional testing completed, unit tests passing, integration testing completed, documented.  Whatever your team agrees that EVERY feature must do to be considered done.  The more mature & disciplined the team, the more complete this list, including things like localization & loc testing complete, security audited, code peer-reviewed, etc.

36. Sprint Review  “Inspect” product  Team presents what was accomplished during the sprint  Typically a demo of new features  Informal No slides Minimal prep  Whole team participates  Invite the world Sprint Planning Meeting Daily Scrum Meeting Sprint Review Meeting Sprint Retrospectiv e Meeting

37. Sprint Retrospective Sprint Planning Meeting Daily Scrum Meeting Sprint Review Meeting Sprint Retrospectiv e Meeting  “Inspect” process  Periodically take a look at what is and what isn’t working  Can be short, sometimes long  Done after every sprint  Whole team participates

38. Retrospectives & Self Management: A Tale of Three Sprints Sprint 7 Sprint 8 Sprint 9

39. Sprint 8 Retrospective  Team frustrated that work is not getting all done in a sprint  We’ve tried deferring earlier, now what?  Team agreed:  Decompose larger stories into much smaller stories for the next sprint  Each story needs to be testable  Mantra for next sprint planning: “and how will we test this?”  Be very careful with check-ins approaching end of sprint Before: After: Uh Oh! No Problem

40. Team “discovered” TDD, further vertical slicing Sprint 7 Sprint 8 Sprint 9  Sprint 9:  Team broke features down smaller  We could defer small stories at any time  Sprint planning meeting was test driven  Completed all work in the sprint!

42. Goals of Agile Engineering Techniques  Remove defects as early as possible  Improve code health, eliminate technical debt  Promote collective ownership & understanding  Deliver razor thin slices as frequently as possible  Work at a sustainable pace

43. Agile Engineering Practices  Test Driven Development  Pair Programming  Peer Reviews  Continuous Integration  Automated Acceptance Testing

45. Example Requirement Requirement 1.05a: The application should automatically save open documents at regular intervals

46. User Stories I want <some function>  User Stories add two pieces of information to a typical requirement:

47. Creating a Product Backlog using User Stories  User Stories: As a <type of user>, I want <some function> so that <some goal>.

48. Example Requirement 1.05a: The application should automatically save open documents at regular intervals Why? Who needs this functionality?

49. Create a Product Backlog using User Stories  User Stories: As a <type of user>, I want <some function> so that <some goal>.  Example: Auto-save document

50. Where are the details?  The product owner’s conditions of satisfaction can be added to the back  These are essentially tests

51. Where are the details?  The larger story can be broken into multiple smaller stories

52. Stories, Themes, and Epics User story A description of functionality told from the users perspective Theme A collection of related stories Epic A really big story

53. Ideas for splitting stories  Focus on “vertical slices”  Tracer Bullet  Break into Acceptance Tests/Conditions of Satisfaction  Then turn those into smaller stories  20 ways to split stories  http://xp123.com/xplor/xp0512/

54. Attributes of a good story  Independent  Negotiable  Valuable  Estimatable  Sized Appropriately  Testable  Eliminate as many dependencies as possible  Stories aren’t contracts, leave or imply some flexibility  To users  Plans are based on stories, so we need to estimate  Small enough to work on in a sprint if it’s close to implementation  How will we know it’s done? No partial credit

56. Agile Planning & Estimation  Goal is always to be accurate  Precision increases as project goes on  Is more focused on planning than the plan  Encourages changes  Results in plans that are easily changed  Is spread throughout the project

57. Estimation accuracy over time X = Time Spent Y = Estimation Accuracy 100% 1 2 3 4 5 6 7 Highest ROI More Certainty, at higher cost

58. Traditional Time Estimates How long will it take to eat all of this candy?

59. Traditional Time Estimates How long will it take to eat all of this candy?  What factors might influence the answer?  Who is doing the work?  Interruptions?  What kind is it?  Motivations?  How tired?

60. Agile Estimates: Relative Size Candy Units = X Candy Units = 3

61. Orders of Magnitude 3 6

62. Orders of Magnitude 3 6 ? ?!?!

63. Limiting the set of possible values  We only estimate well within one order of magnitude  Difference between 3 and 6 is obvious, worth discussing  What about 103 and 106?  Limit possibilities to naturally occurring sets of increasing values:  Fibonacci: 1,2,3,5,8,13,21,etc.  Exponential: 1,2,4,8,16,32,etc.

64. Estimating Size in Story Points  Story Points:  The “bigness” of a backlog item  Influenced by how hard it is, how much there is  Unit is arbitrary, but relative  (6 story point item) should be 2x(3 story point item)  Estimate of getting the story “Done”

65. Estimating with Planning Poker  Iterative, team based approach 1. Each estimator has a deck of cards with potential estimates based on set (Fibonacci, etc.) 2. Product Owner reads a backlog item, brief clarifying discussion occurs 3. Estimators choose a card indicating their estimate 4. Cards are revealed all at once 5. Differences are discussed, especially outliers

67. Two levels of planning Release Planning Sprint Planning Goal Enable product level decisions such as scope, release date, resources required Enable the scrum team to commit to a specific set of work for a given sprint Led By Product Owner Product Owner + Scrum Team Artifac t Product/Release Backlog Sprint Backlog Items User Stories/Features Tasks Units Story Points Task Hours Units over time Velocity Capacity Don’t confuse the goal, items, or units from one level with the activities of the other!

68. Building a Release Plan  Create Product Backlog  One Line Item – but can be months of work  Product Owner leads  Market Research, positioning, etc.  Estimate relative sizes  Determine team velocity Pr i Story Size 1 As an editor, I want a new... 5 2 As a Sys Admin, I need a wa... 8 3 As a novice user, I want a pe... 13 4 As a test engineer, I want to... 13 5 As a pro photographer, I wa... 2 6 As an unregistered user, I ne... 3 7 As a user that never restarts... 8 8 As a developer, I need to ver... 20

69. Velocity  Total story points for all product backlog items meeting the definition of done at the end of a sprint  Averaged over time  Three ways to calculate: 1. Based on historical values 2. Ideally after a sprint or two 3. Forecasted when necessary

70. Projecting Velocity when historic values aren’t available Pr i Story Size 1 As an editor, I want a new... 5 2 As a Sys Admin, I need a wa... 8 3 As a novice user, I want a pe... 13 4 As a test engineer, I want to... 13 5 As a pro photographer, I wa... 2 6 As an unregistered user, I ne... 3 7 As a user that never restarts... 8 8 As a developer, I need to 20  Choose a few stories Pr i Story Size 1 As an editor, I want a new... 5 2 As a Sys Admin, I need a wa... 8 3 As a novice user, I want a pe... 13 4 As a test engineer, I want to... 13 5 As a pro photographer, I 2  Break down to tasks, estimate Task Hours 128 210 272 225 45 Totals: 41 880  Compare totals to sprint capacity Sprint Capacity = ~900 Hours  Calculate Sprint Capacity Projected Velocity = ~ 42 story points per sprint  Estimate Velocity per sprint

71. Calculating Average Velocity (historic)  Average (30) 0 5 10 15 20 25 30 35 40 45 1 2 3 4 5 6 7 8 9 10 11 Velocity Last 8 sprints  Worst Case (23) Lowest 3  Best Case (38) Highest 3

72. Building a Release Plan  Create Product Backlog  Estimate relative sizes  Determine team velocity Pr i Story Size 1 As an editor, I want a new... 5 2 As a Sys Admin, I need a wa... 8 3 As a novice user, I want a pe... 13 4 As a test engineer, I want to... 13 5 As a pro photographer, I wa... 2 6 As an unregistered user, I ne... 3 7 As a user that never restarts... 8 8 As a developer, I need to ver... 20  Average (30) Sprint 1 26 points May4-May31 Sprint 2 26 points Jun1-Jun28 Sprint 3 30 points Jun29-Jul26 Sprint 4 30 points Jul27-Aug23  Update after each sprint

73. Q&A

74. THANK YOU

Agile Development with Scrum.pptx

Agile Development with Scrum.pptx

Recomendados

Mais conteúdo relacionado

Similar a Agile Development with Scrum.pptx

Similar a Agile Development with Scrum.pptx(20)

Último

Último(20)

Agile Development with Scrum.pptx

Notas do Editor