PMI-ACP Training Deck

1. PMI-AgileCertifiedPractitioner PMI-ACPPrepWorkshop LeadingAgile Atlanta 2180 Satellite Blvd Suite 400 Duluth, Georgia 30097 (678) 935 -4664

2. Rick Austin– Enterprise Agile Coach PMI-ACP: Support Team Lead PMI Agile Community of Practice: Volunteer About me… experience applying agile to small teams large distributed teams change management Agile Project Management Volunteer and Leader Expert in Financial Services Industry Georgia State Grad Agile Transition Director, Program Manager Applications Development Manager Solutions Director of Development Information Technology Director

3. 3 Let’s introduce ourselves, find out why we’re all at this session • What is your name? • Why are you here? • What is your level of expertise with Agile? Introductions

4. 4 Write your questions on Sticky notes as they occur to you & affix them to our Learning Backlog. Learning Backlog Backlog

5. 5 Participation is a Key to Success • We will move quickly, but spend appropriate time on material you find especially useful • I should be asking a lot of questions • The key to success for our session is participation o Share your ideas and learning o Tell me when to move on o Tell me when to go into more detail Approach

6. 6 Course Agenda Risk Burndowns Qualitative vs. Quantitative Implicit vs. Explicit Scrum Basic Understanding Scrum Process Overview Planning Requirements Estimation Roles & Responsibilities Product Owner ScrumMaster The Team The Scrum Process Initial Planning Product Backlog Release Planning Sprint Planning Sprint Backlog Sprint Sprint Review Daily Scrum Sprint Retrospective Simulations and Exercises Command-and-Control Exercise Self-Organization Exercise Batch and Flow Exercise Team Collaboration Exercise Theory of Constraints Exercise User Story Writing Planning Poker Affinity Estimating Iteration 0/Release Planning Sprint Planning Daily Standup Review and Demo Retrospective Exam Content Overview What is the PMI-ACP Domains and Tasks Content Distribution Tools & Techniques Knowledge & Skills Community Guide of the PMI-ACP Agile History Leaders over time Waterfall Agile Manifesto Why Agile? Understanding the basics Agile Methods Lean Kanban Extreme Programming Scrum

7. WhatisthePMI-ACP?

8. 8 PMI-ACP is not: • A replacement for the PMP® • PMI’s own flavor of Agile • Without support from the Agile community • Going to make you an Agile expert Agile is not: • Something New • A silver bullet • An excuse for little or no planning • An excuse for little or no documentation • An excuse for poor quality • Undisciplined • Unproven What the PMI-ACP and Agile are Not ≠

9. 9 Based on Geoffrey Moore’s Technology Adoption Life Cycle Curve PMI-ACP and Adoption Curve The chasm PMPACP We are here!

10. 10 Knowledge & Skills (50% of exam) Percentage of Knowledge and Skill Content / % of Exam Level 1 (66% / 33%) (18 knowledge/skills) Level 2 (24% / 12%) (12 knowledge/skills) Level 3 (10% / 5%) (13 knowledge/skills) Active listening Agile frameworks and terminology Agile contracting methods Agile Manifesto values & principles Building high-performance teams Agile project accounting principles Assessing and incorporating community and stakeholder values Business case development Applying new Agile practices Brainstorming techniques Colocation (geographic proximity)/distributed teams Compliance (organization) Building empowered teams Continuous improvement processes Control limits for Agile projects Coaching and mentoring within teams Elements of a project charter for an Agile project Failure modes and alternatives Communications management Facilitation methods Globalization, culture, and team diversity Feedback techniques for product (e.g., prototyping, simulation, demonstrations, evaluations) Participatory decision models (e.g., input based, shared collaboration, command) Innovation games Incremental delivery PMI's Code of Ethics and Professional Conduct Principles of systems thinking (e.g., complex adaptive, chaos) Knowledge sharing Process analysis techniques Regulatory compliance Leadership tools and techniques Self assessment Variance and trend analysis Prioritization Value-base analysis Variations in Agile methods and approaches Problem-solving strategies, tools, and techniques Vendor management Project and quality standards for Agile projects Stakeholder management Team motivation Time, budget, and cost estimation Value-based decomposition and prioritization

11. 11 Tools & Techniques (50% of exam) Communications • information radiator, team space, agile tooling, osmotic communications for colocated and/or distributed teams, daily stand-ups Planning, monitoring, and adapting • retrospectives, task/Kanban boards, timeboxing, iteration and release planning, WIP limits, burn down/up charts, cumulative flow diagrams, process tailoring Agile estimation • relative sizing/story points, wide band Delphi/planning poker, affinity estimating, ideal time Agile analysis and design • product roadmap, user stories/backlog, story maps, progressive elaboration, wireframes, chartering, personas, agile modeling Product quality • frequent verification and validation, test-driven development/test first development, acceptance test-driven development, definition of done, continuous integration Soft skills negotiation • emotional intelligence, collaboration, adaptive leadership, negotiation, conflict resolution, servant leadership Value-based prioritization • return on investment (ROI)/net present value (NPV)/internal rate of return (IRR), compliance, customer- valued prioritization, minimally marketable feature (MMF), relative prioritization/ranking Risk management Metrics • risk- adjusted backlog, risk burn down graphs, risk-based spike Metrics Including but not limited to: velocity, cycle time, earned value management (EVM) for agile projects, escaped defects Value stream analysis • value stream mapping

12. 13 Community Guide of the PMI-ACP Source: PMI.org/Agile

13. AgileHistory

14. 16 • On February 11-13, 2001, at Snowbird ski resort, seventeen people met to talk, ski, relax, and try to find common ground. • Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened. • What emerged from this meeting was a symbolic Manifesto for Agile Software Development, signed by all participants. Agile Manifesto

15. 17 Agile is Not New 1943 1950- 1960s 1985 1990 1995 1996 1997 1998 2000 2001 USAF & NASA X-15 hypersonic jet Iterative Incremental Delivery Hirotaka Takeuchi & Ikujiro Nonaka The New New Product Development Game 1990 - Sutherland & Schwaber Scrum Framework DSDN Consortium Dynamic System Development Method 1996 - Beck, Cunningham, Jeffries Extreme Programming Jeff de Luca Feature Driven Development Alistair Cockburn Crystal Methodologies Robert Charette Lean Development Agile Manifesto Taiichi Ohno Toyota Production System Kanban Hardware Software

16. 18 Agile Practices Lean Kanban PMBOK Agile is an umbrella term for a group of iterative and incremental software development methods.

17. 19 Agile Tools Process Tools VersionOne Rally Software JIRA + GreenHopper Team Foundation Server Excel Kanban AgileZen LeanKit Kanban Kanbanery Engineering Tools Continuous Integration http://jenkins-ci.org/ http://hudson-ci.org/ http://cruisecontrol.sourceforge.net/ Engineering Tools Ruby Cucumber for ATDD/BDD: http://cukes.info/ RSpec: http://rspec.info/ Java http://www.junit.org/ http://www.jmock.org/ .Net http://www.nunit.org/ BDD for .NET: http://www.specflow.org/ http://www.nmock.org/

18. 20 Agile Manifesto Values Individuals & interactions Processes & toolsover Working software Comprehensive documentation over Customer collaboration Contract negotiationover Responding to change Following a planover That is, while there is value in the items on the right, we value the items on the left more. We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Source: www.agilemanifesto.org

19. 21 Agile Manifesto Principles Satisfy the Customer Welcome Change Deliver Frequently Collaborate Daily Support & Trust Motivated Teams Promote Face-to-Face Conversations Deliver Working Software Promote Sustainable Pace Promote Technical Excellence Maximize Through Simplicity Have Self-Organized Teams Reflect & Adjust Regularly Source: www.agilemanifesto.org

20. UnderstandingtheBasics

21. 28 Flipping the Iron Triangle Features Cost Date Cost Date Features Source: DSDM Plan- Driven Value- Driven $

22. 29 Agile methods support experimentation & adaptation by reducing the cost of change. This is done by employing many concurrent, rapid feedback loops to surface and address risks early. Reducing the Cost of Change Source: Examining the Cost of the Agile Change Curve by Scott Ambler

23. 30 Common Understanding A document can’t generate the meaning in others that conversations can. There is a reason “Individuals and Interactions” is first in the Agile Manifesto. ? ? ! We don’t need an accurate document, we need a shared understanding - Jeff Patton / Agile 2012

24. 31 Deploy Document $ Incremental Value Delivery Agile Concurrent Development • Fund incrementally – opt to extend, redirect or cancel at a very granular level • Deliver & realize value steadily • Validate designs with users & customers • Continuously adapt to risk and change • Integrate early & often Waterfall Serial Development Invest up front, only realize value at end, assuming value proposition hasn’t changed Test Code Design Analyze $$$ Analyze Design Code Test Deploy Document Analyze Design Code Test Deploy Document Analyze Design Code Test Deploy Document $ $$

25. 32 Collaboration and Feedback Loops Traditional methods only work for so long because… • No or little feedback before delivery. • Change not expected. Why are agile methods being considered? • Constant feedback loops. • Change is expected.

26. 33 Process Burden or Lack of Discipline • Historically development teams have faced a false choice in respect to process o Overly complex and burdensome o Or, undisciplined with no controls • Agile Provides a lightweight, but disciplined approach for speeding time to market, improving quality, and increasing predictability Agile is Discipline w/o Undue Burden

27. 34 Four volunteers, please! Time is set at 2 minutes Estimate throughput Round 1 (measure first and last delivery time) • First person flips 50 coins • When done with entire batch, pass to next person Round 2 • First person flips one coin of highest value and passes to next person • Keep flipping and passing until done Round 3 • Each table creates their own rules to maximize coin flow/throughput in least amount of time Retrospective Exercise – Batch vs Flow Throughput

28. 35 Key Agile Principles Traditional Waterfall Focus on Highest Value First Align project, product and team visions by prioritizing by business needs, and using well architected code, to deliver better quality products faster and cheaper. All or nothing Tight coupling & bias toward building out internals in a breadth first fashion means that nothing can be delivered in isolation, even if it’s valuable. Responding to Change Acknowledge uncertainty & adapt to both external (market) and internal changes, by modifying plans & approach. Use engineering principles to make code base easy to modify. Baseline & Change Control Constrain or even completely eliminate any significant change other than dropping features. Work to initial plans, even when they are proven to be invalid. Iterative Use short time boxes to provide a rhythm, continually flow of value to the customer, and refine deliverables over time. Phased No rhythm as project is executed using long phases. Feedback & Continuous Improvement Use continual feedback to inform plans and modify approach. Lessons Learned at the End Feedback is rarely given in time for it to be applied towards improving processes and project execution. Small, Integrated Teams A small team size, and overlap in skills sets, simplifies communications, allows everyone to see the big picture, creates self discipline and provides flexibility. Silo Teams with Handoffs Staff works in functional oriented groups, throwing documentation and code over the wall. Technical Excellence / Bake Quality In Use TDD , ATDD, refactoring, and other strong engineering principles to ensure quality. Inspection Attempt to ensure quality by after the fact inspection. Agile Principles Compared

29. 36 Agile is Empirical, Not Definitive Agile assumes that baselines may change significantly during the project. In such an unpredictable environment, empirical methods should be used to monitor progress and direct change, rather than using definitive methods to try and predict progress and stop change.

30. 37 Rolling Wave Planning, used in Agile processes, embraces the Lean ideal of making decisions at the last responsible moment, when the most possible information is available. This maximizes flexibility and planning accuracy. Agile Uses Rolling Wave Planning Level of Planning Planning Approach Strategic product line goals Strategic Planning Strategic product goals Product Planning Specific problems to solve Lean / Six Sigma Large functional goals Release Planning Small, defined work items Iteration Planning Tactical organization & execution Daily Standup

31. 38 Layers of Product Planning Product / Project What business objectives will the product fulfill? Product Goals Product Charter Elevator Pitch Release How can we release value incrementally? What subset of business objectives will each release achieve? What user constituencies will the release serve? What general capabilities (big stories) will the release offer? Release Roadmap Release Plan Iteration / Sprint What specifically will we build? (User Stories) How will this iteration move us toward release objectives? Iteration Plan Development Tasks Story (Backlog Item) What user or stakeholder need will the story serve? How will it specifically look and behave? How will I determine if it’s completed? Story Details Acceptance Tests

32. 39 • Top level goal(s) must be communicated to all levels of the organization • Members of the organization offer candid information up the management ladder. • Leaders/Managers offer guidance (why and what ≠ how) Principle - Self-Organized and Empowered info guide info guide info guideinfo guide

33. 40 Some Basic Terminology Scrum Extreme Programming (XP) Definition Sprint Iteration Fixed-length period of time (timebox) Release Small Release Release to production Sprint/Release Planning Planning Game Agile planning meetings Product Owner Customer Business representative to project Retrospective Reflection “Lessons learned”-style meeting ScrumMaster Coach Agile project manager Development Team Team Empowered Cross-Functional team Daily Scrum Daily Standup Brief daily status meeting

34. 41 Some More Agile Terminology Term Definition Spike Something cannot be estimated until a development team runs a timeboxed investigation. The spike itself is a throw-away. Can include risk, architectural, or any unknown. Tracer Bullet An experimental solution that cuts through all the "layers" of the architecture. It is not necessarily time-boxed. It is not intended to be thrown away. Kaizen Continual improvement of all areas of a company not just quality. Value Stream An end-to-end business process which delivers a product or service More terms… Go to the Community Guide of the PMI-ACP at http://agile.vc.pmi.org/

35. 42 Session Purpose Timing/Duration Attendees Iteration 0 Orient Team to project’s business value and analytical background, the process, and one another. Start of project Approximately 1-3 weeks of 2-4 hr workshops Team, PO, SM, Key Stakeholders & users Release Planning Determine what a Release should include and when it should be delivered. Start of Release 2-4 hours PO, SM, Key Stakeholders, optionally Team Daily Standup Facilitate rapid coordination between Team members, and with PO. Daily 10-15 minutes Team, SM, PO Iteration Planning Elaborate, estimate and prioritize highest- value Product Backlog items for an Iteration. Start of each Iteration 2-4 hours Team, SM, PO Iteration Retrospective Reflect on project & process issues and take action as appropriate. End of each Iteration 30-45 minutes Team, SM, PO Iteration Review Demonstrate completed functionality to interested stakeholders & users to show progress and gain feedback. End of each Iteration 1-1½ hours Team, PO, SM, Key Stakeholders & users Meetings Summarized

36. 43 Small Teams with everything needed to deliver an increment of value Backlog prioritized by value being delivered incrementally At scale, the backlog and products for these teams need to be coordinated and technical practices must address the challenges of integration How does Agile Work?

37. 44 Deploy Document $ Incremental Value Delivery Agile Concurrent Development • Fund incrementally – opt to extend, redirect or cancel at a very granular level • Deliver & realize value steadily • Validate designs with users & customers • Continuously adapt to risk and change • Integrate early & often Waterfall Serial Development Invest up front, only realize value at end, assuming value proposition hasn’t changed Test Code Design Analyze $$$ Analyze Design Code Test Deploy Document Analyze Design Code Test Deploy Document Analyze Design Code Test Deploy Document $ $$

38. 45 Incremental and Iterative Delivery Incrementing is more about delivery. 1 2 3 4 5 1 2 3 4 5 Iterating allows you to move from vague idea to realization. Going from rough to polished Image Credit: Jeff Patton

39. 46 • Iterations are regularly scheduled, pre-planned, recurring time boxes. Provide a cadence / rhythm that provides predictability and synchronization points for planning. The more mature your process, the shorter the iterations. • Things we time-box: o Sprints (or Iterations) - length of time in which work is done o Releases - Production and Maintenance o Working Sessions - Release Planning, Sprint Planning, Sprint Review, Retrospective • Iterations facilitate incremental development (but incremental development doesn’t require iterations). Iterations

40. AgileMethods Lean Kanban Extreme Programming Scrum

41. 48 “A production practice that considers the expenditure of resources for any goal other than the creation of value for the end customer to be wasteful, and thus a target for elimination.“ What is Lean? Source: Wikipedia

42. 49 Kanban (看板) literally meaning "signboard" or "billboard", is a concept related to lean and just-in- time (JIT) production. Taiichi Ohno is considered to be the father of the Toyota Production System What is Kanban? Kanban is a scheduling system that tells you what to produce, when to produce it, and how much to produce.

43. 50 • A software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. • It advocates frequent "releases" in short development cycles, which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted. What is Extreme Programming?

44. 51 Scrum is an iterative and incremental project delivery framework. What is “Scrum?” Source: Wikipedia

45. 52 Iteration 0 Brief orientation to the project’s business value and analytical background, the Agile process, and the Team. Project Orientation • Business case overview • Business process analysis • Project scope & objectives • Initial Product Backlog Process Orientation • Agile process training • Sprint/Release cycles • Definition of “Done” Team Orientation • Team room artifacts • Team norms • Technical environments, design, architecture, etc Initiating an Agile Project Release Planning Session Initial project planning, to review initial Product Backlog and set production Release dates. Release Schedule Product Backlog List of desired functionality prioritized by business value by Product Owner. Allow a user to create a free account. (Priority 1) Allow subscribers to purchase music. (Priority 3) Allow user to personalize store experience. (Priority 9)

46. 53 A useful project charter contains three key elements: 1. Vision: The vision defines the “Why” of the project. This is the higher purpose, or the reason for the project’s existence. 2. Mission: This is the “What” of the project and it states what will be done in the project to achieve its higher purpose. 3. Success Criteria: The success criteria are management tests that describe effects outside of the solution itself. Additional elements: Working practices – Planning, estimating, definition of done, tracking progress, TDD methods Continuous Integration – integration time limits, breaking the build, code check-in Code – Paired programming, owning the code, documentation Iterative and Incremental Development – iteration cycle and deployment cycle Agile Project Charter

47. Lean

48. 55 Lean Portfolio Management • Corporate strategy operates over years with direct line of sight to priorities • Optimize the whole • Manage internal and external dependencies • Focus on quickly delivering minimal marketable features • Clear feedback mechanism between business and development • Creates alignment beyond single teams Year(s): Set corporate goals and strategies Quarter(s): Discover and create innovative product strategies from corporate goals Month(s): Update Release Plans, Product Backlogs and Roadmaps Week(s): Decompose features from Product Backlog into tasks and deliver working code

49. 56 The 7 Principles of Lean 1. Eliminate Waste 2. Create Knowledge 3. Build Quality In 4. Defer Commitment 5. Optimize the Whole 6. Deliver Fast 7. Respect People 7 Principles of Lean Source: Mary and Tom Poppendieck

50. 67 Process Cycle Efficiency is the key measure of Leanness Process map entire value-stream at a high level, drilling down into more detail only as potential areas of interest are identified • Value-added: This step in the process adds form, function, and value to the end product and for the customer. • Non-Value-Added: This step does not add form, function, or assist in the finished goods manufacturing of the product. • Non-Value-Added-But-Necessary: This step does not add value, but is a necessary step in the final value-added product. Lean Process Cycle Efficiency PCE = (sum of time for Value Added process steps) (sum of time for All process steps)

51. 70 The “Kaizen” Mindset: 1. Everything, not just software development, can and should be improved 2. Improvements should be made day to day 3. The best improvements come from taking the customer’s point of view 4. Move from criticism to suggestion 5. Keep improving, even if things are working Continuous Improvement 改善

52. Kanban

53. 74 1. Visualize your Workflow 2. Limit Your Work in Process Example: Mature Requirements Separately • Instead of figuring everything out for a user story just in time at Sprint Planning, we can ready them in advance • The specific process varies, but there is a set of steps to get a requirement ready Kanban – High Level New Candidates PO Approved Decomposed Acceptance Criteria Testable Example Dev Review Ready for Sprint 10 cards 6 cards 4 cards 4 cards 4 cards 8 cards 12 cards

54. Airplane Game Paper Airplane Game  Team of 5 makes 21 airplanes  1st Run: Fast as you can  2nd Run: Flow, Batch size of one  Consistently better results – Lead Time: 3X improvement – Throughput: 10-20% better – Lower stress – Easier to manage

55. 76 Everything at once = many started few finished Costs of Over-Utilization Develop Test In Process Ready In Process Ready 4 slots 3 slots 4 slots 3 slots WIP Limits = Fast “A system of local optimums is not an optimum system at all” - Eli Goldratt

56. ExtremeProgramming(XP)

57. 78 Agile Engineering Practices allow teams to move fast, be flexible and deliver high quality software: • Automated Builds & Continuous Integration reduce time and effort associated with manual builds, and risk from big-bang integrations • Simple Design & Refactoring keep incremental development from leading to poor architectures • Multi-Level/Automated Testing & Test- Driven Development reduce testing time and effort and allow developers to make changes with confidence • Pair Programming increases software quality without impacting time to deliver. Agile Engineering Practices Source: Bill Wake, http://www.xp123.com

58. 79 XP Coach • The XP Coach role helps a team stay on process and helps the team to learn. A coach brings an outside perspective to help a team see themselves more clearly. The coach will help balance the needs of delivering the project while improving the use of the practices. A coach or team of coaches supports the Customer Team, the Developer Team, and the Organization. • The decisions that coaches make should always stem from the XP values (communication, simplicity, feedback, and courage) and usually move toward the XP practices. As such, familiarity with the values and practices is a prerequisite. The coach must command the respect required to lead the respective teams. The coach must possess people skills and be effective in influencing the actions of the teams. • The XP Coach uses many different techniques. The coach is a mentor, working side by side with team members on their tasks. The coach is a facilitator, helping achieve more effective team performance. The coach is a conduit, reinforcing communication within the team and across teams. XP Roles - Coach

59. 80 XP Customer • The XP Customer role has the responsibility of defining what is the right product to build, determining the order in which features will be built and making sure the product actually works. • The XP Customer writes system features in the form of user stories that have business value. Using the planning game, he chooses the order in which the stories will be done by the development team. Defines acceptance tests that will be run against the system to prove that the system is reliable and does what is required. XP Roles - Customer

60. 81 XP Programmer • The XP Programmer is responsible for implementing the code to support the user stories. XP Roles - Programmer

61. 82 XP Tester • The primary responsibility of the XP Tester is to help the customer define and implement acceptance tests for user stories. The XP Tester is also responsible for running the tests frequently and posting the results for the whole team to see. As the number of tests grow, the XP Tester will likely need to create and maintain some kind of tool to make it easier to define them, run them, and gather the results quickly. XP Roles - Tester

62. 83 1. ______ is responsible for implementing the code to support the user stories. 2. ______ help the customer define and implement acceptance tests for user stories 3. ______ Helps a team stay on process and helps the team to learn. Is a mentor, working side by side with team members on their tasks 4. ______ writes system features in the form of user stories that have business value and defines acceptance tests. XP Roles – Quick Quiz a) XP Coach b) XP Customer c) XP Programmer d) XP Tester 1(c)2(d)3(a)4(b)

63. 86 Simple Design: • Code is always testable, browsable, understandable, and explainable • Do the simplest thing that could possibly work next. Complex design is replaced with simpler design • The best architectures, requirements, and designs emerge from self- organizing teams Refactoring: • Remove redundancy, eliminate unused functionality, and rejuvenate obsolete designs • Refactoring throughout the entire project life cycle saves time and increases quality • Code is kept clean and concise so it is easier to understand, modify, and extend Simple Design and Refactoring

64. Risk

65. 94 Create a risk census during the first sprint planning meeting and then update it quickly during subsequent planning meetings as new risks are identified or as the probabilities or sizes of known risks change. Risk Burndown As with a regular release burndown chart, we should see a linear drop in risk over the course of the project. Plot your project risk exposure and display it with other big visible charts in your team area. Source: Managing Risk on Agile Projects | Mike Cohn - Mountain Goat Software

66. 95 Risk Management Traditional Risk Management Agile Risk Management Prepare formal risk management plan Educate the team. Invite them to determine best approach to manage Formal risk identification meetings and then create Risk Register Team identifies risks in all meetings and add to information radiators Conduct qualitative and quantitative analysis. Determine how to respond Facilitate the team in a qualitative analysis, determine how to respond, post results Periodically review Risk Register and make updates as needed Constantly review risk and responses as part of all meetings, reviews and retrospectives Source: Sliger & Broderick (2008),The Software Project Manager's Bridge to Agility, Addison-Wesley

67. 96 Implicitly managing Risk: • User stories are prioritized by the Product Owner o Highest value items are attacked first o Highest risk items are also attacked early • Iterative delivery ensures that integration and rollout risks are attacked very early in the project lifecycle • Technical discipline helps keep a tight rein on development risk o Automated builds and continuous integration keep code integration and code quality risk to a minimum Implicit Risk Management

68. 97 Explicitly managing Risk: • Review the Product Backlog • Identify and list risks by impact (High/Medium/Low) and probability (High/Medium/Low) • Provide a mitigation plan with clear responsibility • Create task cards for risk mitigation items • Insert into Product Backlog and/or Sprint Backlogs; or track on Risk Board Explicit Risk Management Agile Risks, Agile Rewards, Smith and Pichler, Dr. Dobb’s 2005

69. AgileRequirements

70. 99 User Interface Layer Business Logic Layer Persistence Layer Work in Agile projects is organized by Units of Value, rather than by Architectural Layer. Work Organized by Value Feature / User Story 2Feature / User Story 1 Feature / User Story 3

71. 100 Key Characteristics • High-level descriptions of desired functionality and goals • Implement “vertical slices” of the system’s functionality • “Contracts for conversation,” not all-inclusive requirements • User stories wait in the Product Backlog until pulled into the Sprint Backlog • Contain Acceptance Criteria to define “Done” User Stories at a Glance As a user I can create an account. Estimate 21 Points Priority 1 (High) As a user I can enter a user name. Estimate 4 points Priority 1 (High) As a user I can enter password. Estimate 8 points Priority 1 (High) Product Backlog User Story Sprint Backlog User Stories

72. 101 From User Stories to Tasks Tasks As a user I can enter a password. Estimate 8 points Priority 1 (High) Acceptance Criteria User Story On back… • Design user interface • Develop CSS/HTML • Create database fields • Develop validation criteria • Write test cases • Code test fixtures • Unit testing • Acceptance testing • Usability testing • Write online help text • Password match validated • Contains special characters • Minimum 10 digits • Cannot be text only

73. 102 As a <type of user>, I can <immediate goal> so that <business outcome>. User Story Template User Role (Who?) Desired Function (What?) End Result (Why?) Who, What, Why… what’s not here?

74. 103 Acceptance Criteria help to set scope and define what Done means for a given User Story. User Story Acceptance Criteria • Verify that a premium member can cancel the same day without a fee. • Verify that a non-premium member is charged 10% for a same-day cancellation. • Verify that an email confirmation is sent. • Verify that the hotel is notified of any cancellation. As a user, I can cancel a reservation.

75. 104 Circle which attributes make a good story and then discuss as the group What Makes a Good Story? Independent Valuable Testable CreativeEstimatable Small Negotiable Source: Bill Wake

76. 105 Pre Release Life of a User Story • Phone # in US format, contains no alpha characters, minimum 10 digits • First name, Last name and email address required • Email specified in standard format • Etc. Acceptance Criteria Created Prior to Release Planning As a user I want to create an account User Stories Created Prior to Release Planning Sprint Tasks Created at Sprint Planning • Design UI Mock Up • Write online help text • Develop CSS/HTML • Develop validation criteria • Create database tables • Code test fixtures • Code • Perform testing Name Phone Email Valid John Smith 215-555-1212 jsmith@ls.com TRUE Smith 215-555-1212 jsmith@ls.com FALSE John 215-555-1212 jsmith@ls.com FALSE 215-555-1212 jsmith@ls.com FALSE John Smith jsmith@ls.com FALSE Smith jsmith@ls.com FALSE John jsmith@ls.com FALSE Testable Examples (ATDD) Created Prior to Sprint Planning Estimate 5-Points Priority 1 -High (Created at Release Planning)

77. 106 User Stories aren’t the only way to develop, express and elaborate requirements in Agile. Some complementary tools & methods include: • Essential Use Cases • Low-fidelity prototyping • High-fidelity prototyping The best approach will be determined by your team and the problems at hand. Beyond User Stories

78. 107 Low-fidelity prototyping is a fast, cheap, easily iterated, collaborative way to test various concepts & approaches. Low-Fidelity Prototyping in Agile Tools • Paper sketches and collages • Whiteboard drawings Applications • Concept design: to explore different metaphors and design strategies • Interaction design: to organize screen structure & flow • Screen design: for initial screen layout & design • Screen testing: to refine screen layout Source Adaptive Path for Sketchboard example

79. 108 High-Fidelity prototypes are detailed, interactive and reusable means of simulation. Tools: • Photoshop, Visio, Powerpoint • Flash, iRise Studio, Serena ProcessView • WPF, XAML, XUL… Applications: • When stable requirements support reuse • To test complex interaction scenarios • To finalize detailed designs • As inputs to a Sprint High-Fidelity Prototyping in Agile Source: iRise Studio, www.irise.com

80. 109 1. In general, we can view the maturation of a need (expressed as a user story) as having enough information to prioritize, __________ and ___________. 2. The user story format has three parts: “as a”, “I want to” and “_________.” 3. Acceptance criteria is written for team members and, as such, assumes a level of existing ___________. 4. Acceptance criteria is incredibly useful but a ___________ will often provide significant additional clarity. Agile Requirements a) build b) domain knowledge c) estimate (test) d) outsiders e) so that f) testable example 1(c)(a)2(e)3(b)4(f)

81. 110 5. A ___________ defines how the software will be implemented; it can define the external behavior, ___________ design, or both. 6. As defined in this training, a specification builds on a requirement with additional context, conversations and ___________. 7. A specification should be ___________, defining just enough to help the team build confidently within the sprint. 8. The appropriate level of detail required in a specification will ___________, depending on, among other things, the ___________ of the requirement, the domain knowledge of the team, and the requirements’ similarity to what has already been built. Agile Requirements g) complexity h) designs i) internal j) lightweight k) specification l) vary 5(k)(i)6(h)7(j)8(l)(g)

82. AgileEstimation

83. 112 High Level – Affinity Story Level – Planning Poker Story Points o Purely relative measure of complexity (2 is half as hard as 4) o Variability averages out across many stories o Don’t decay over time Scales with increasing gaps between elements are preferred o Fibonacci: 1, 2, 3, 5, 8, 13 o Doubles: 1/2, 1, 2, 4, 8, 16 o “T-Shirt Sizes:” S, M, L, XL, XXL Agile Estimation Levels, Units and Sequences Traditional project estimation approaches may be necessary for initial scoping, but should rapidly be replaced by empirical observation of Team output capacity (velocity). Avoid false precision to avoid false expectations.

84. 113 1. Use more than one person. By engaging the team in the estimation process, we gain the benefits of additional insights and consensus building. 2. Use more than one approach. Use multiple estimation approaches (comparison to similar projects, bottom up, user story points, etc.) and look for convergence between multiple approaches to reinforce likely estimate ranges. 3. Agree on what “It” and “Done” means. Make sure everyone is estimating in the same units, have the same assumptions and are based on standard developer ability/effort. 4. Know when to stop. Balance estimation effort against the diminishing returns and false accuracies of over analysis. 5. Present estimates as a range. Estimates are often poor predictions, and should be noted as such. 6. Defend/explain estimate range probabilities. Educate stakeholders about the relative likelihood of hitting optimistic/pessimistic estimates. 7. Don’t reserve estimating for when you know least about the project. Estimation should not be reserved for only the beginning of projects. 8. Be aware of common estimation omissions. Don’t overlook commonly missed tasks, and use retrospectives to inspect project-specific issues. 9. Embrace reality early. Don’t under-estimate the load of maintaining and refactoring a growing codebase. 10. Review, Revisit, Remove Head from Sand, Repeat. Adjust project forecast based on empirical observation of throughput. Agile Estimation Essentials

85. 114 Participants: Whole team Multi-team environment: Work together! Process: Cards are placed in a stack on the table • Product Owner explains the top card • First team member places this card on table by size (left smaller, right larger) • Next team member either repeats process with next card, or moves an existing card to a new position, with an associated explanation • Process repeats until all cards are placed and grouped, and no more movement is desired • Each group is labeled with its estimate Affinity Estimating Smaller Larger

86. 115 • Clifford the Big Red Dog • Marmaduke • English Bulldog • Chihuahua • Pug • Scooby-Doo • Great Dane Exercise – Relative Dog Sizing Rules Point Estimating: Team decides scale Discuss criteria for complexity Find the reference point Estimate size for remaining items Based on Mike Cohn’s dog points

87. 116 “Planning Poker” is based on “Wideband Delphi” convergent estimation techniques. How to do it: 1. Each estimator (someone who could possibly be doing the work in question) is given a deck of cards, each card has a valid estimate written on it 2. A moderator reads a story and it’s discussed briefly 3. Each estimator selects a card to represent her estimate 4. Cards are turned over so all can see them 5. Discuss differences (especially outliers) 6. Re-estimate until estimates converge (or don’t!) Agile Estimation – Planning poker

88. 117 5 Planning Poker Example 55Bill (Dev) 52Ann (BA) 58Vijay (QA) 33Susan (Dev) Round 2Round 1Estimator

89. Scrum

90. 119 Scrum – 50,000 Foot View Release Planning Sprint Planning Sprint Review Sprint Retrospective

91. 120 There are only three roles defined in Scrum: Scrum Roles & Responsibilities Product Owner • Owns Product vision • Defines features, decides on release date and content • Responsible for market success • Prioritizes features according to market value • Can change features and priorities every Sprint ScrumMaster • Responsible for facilitating process • Focuses Team and protects them from external interruption • Looks for ways to enhance productivity • Assists Product Owner in leveraging Scrum The Team • Small group containing all necessary project skills • Focuses on steady delivery of high quality features • Generates options for delivery • Manages own work within Sprints

92. 121 • Product Backlog Prioritized list of valuable items to deliver during the project. • Sprint Backlog List of committed items to be addressed within a Sprint. • Burndown/burn-up Chart Visual aid for tracking team progress and forecasting expected completion dates. • Velocity Chart Tracks rate of feature completion. Artifacts of Scrum

93. 122 Scrum Milestones Product Backlog • ____________ • ____________ • ____________ • ____________ • ____________ F3 F6 Release 1 F1, F2, F3 Release 2 F1, F2, F3 F4, F5, F6 Initial Planning ReleasePlanning ReleasePlanning F1 F2 F2 F1 F4 F5F3 U S 1 U S 2 U S 3 U S 4 U S 5 U S 6 U S 7 U S 8 U S 1 U S 2 U S 3 U S 4 U S 5 U S 6 U S 7 U S 8 ReleasePlanning Sprint Backlog • ______ • ______ Sprint Backlog • ______ • ______ Sprint Backlog • ______ • ______ Sprint Backlog • ______ • ______ Sprint Backlog • ______ • ______ Sprint Backlog • ______ • ______ SprintPlanning SprintPlanning SprintPlanning SprintPlanning SprintPlanning SprintPlanning

94. 123 Scrum Milestones Features User Stories MMF

95. 124 The Scrum Sprint Cycle Sprint Planning Elaboration, estimation and prioritization of highest-value User Stories. Sprint Backlog Allow a user to enter a login & password. Allow a user to enter personal information. Allow user to enter billing information. SprintExecution Complete Sprint Backlog Team works on highest-value functionality until it meets jointly defined Acceptance Criteria. Sprint Review Team demonstrates completed functionality to interested stakeholders, gathering feedback. Retrospective Team reflects on project & process and takes action as appropriate. Production Release (Optional) Generally occurs when a useful group of related functionality has been completed. Daily Scrum (or Standup) 15-minute status and risk management meeting for Team & Product Owner.

96. 125 Use a cadence of recurring working sessions to synchronize and simplify planning while providing continuity Cadence & Synchronization Instead of wasting time coordinating numerous meetings and dates…

97. 126 Instead of cube farm, organized by function… We collaborate via flexible roles and simple rules to decentralize decision making and get work done. Small Collaborative Teams AfterBefore

98. 127 SB Item Priority Hours User Story High Task 1 4 Task 2 12 Task 3 6 User Story Med Task 1 9 Task 3 2 User Story Low Task 1 5 Task 2 2 Task 3 7 From Product to Sprint Backlog Product Backlog Sprint BacklogSprint Planning Sprint Top priority stories are discussed and decomposed into Tasks for the Sprint Backlog. Team pulls and completes Tasks until each User Story is done. PB Item Priority Points User Story High 5 User Story High 8 User Story High 3 User Story Med 13 User Story Med 8 User Story Med 5 User Story Med 13 User Story Med 8 User Story Med 5 User Story Low 21 User Story Low 13

99. 128 Cards move left to right, downstream, if there is space. Tracking Work in a Sprint Sprint Backlog In Progress Completed 10 cards 6 cards Sprint Backlog In Progress Completed 10 cards 6 cards Sprint Backlog In Progress Completed 10 cards 6 cards Cards move left to right, assuming there is space, then… From Sprint Backlog to In Progress, if there is space, and… From In Progress to Completed.

100. 129 1. The ___________ ensures that requests are expressed in user story or other appropriate format and placed in the ___________. 2. The ___________ provides story point estimates for each ___________. 3. Product owners ___________ user stories (PBIs), then, with input from the team and other stakeholders, sequences user stories into ___________. Scrum Process Review a) user story b)product owner c) product backlog d)prioritize e) releases f) team 1(b)(c)2(f)(a)3(d)(e)

101. 130 4. At the end of each ___________ the team demonstrates _____________ they do this at the ___________. 5. The total story points estimates, for those stories that were completed in a sprint, are added together to provide us with the ___________ for the sprint. 6. The team holds a ___________ to evaluate how well they’ve done and what changes could be made to the process to further improve. Scrum Process Review g) sprint h)sprint review i) sprint retrospective j) velocity k) working software 4(g)(k)(h)5(j)6(i)

102. Roles&Responsibilities

103. ProductOwner

104. 133 Manage the return on investment (ROI) • Establishes baseline target ROI • Measures project against this baseline • Prioritizes product backlog to maximize ROI Guide product development • Establishes, communicates and nurtures the vision • Knows what to build and in what sequence • Tunes the vision with the team Call for releases • Decides when to call for release of a potentially shippable product increment • Can shift a release forward to maximize ROI based on new knowledge Product Owner Responsibilities

105. 134 Busy Product Owners need not – and should not – act alone. Some of the roles that can assist: • Business Analysts help to define business needs and elaborate them for the rest of the Team • Developers provide available execution paths and describe their respective costs and benefits • User Experience experts and marketing resources help to elicit and explain end user needs and desires • Other Business Stakeholders to get a wider representation of needs from across the organization An Army of One? Product Owners represent many constituents with a single voice.

106. 135 Shared Understanding of Value The Product Owner helps to spearhead a Shared Vision, but the whole Team should understand it: • Communicate & elaborate early conceptual & visioning work through Sprint (Iteration) 0. • Involve Team in translating User Needs into Product Functions • Involve Team in development of clear Goals • Directly involve Team in feedback loops • Provide direct exposure to end users

107. 136 Sarah, the client product manager for your development project, has little interest in being a product owner. “We’ve given you the specification of exactly what we want done,” she declares. “Just do your thing. I know you guys are good!” What do you do? Reluctant Product Owner

108. 137 Sprint What must be in place for your project teams to plan and estimate 2-3 weeks worth of work? (e.g. wireframes, detailed acceptance criteria, key stakeholder approval…) Defining “Ready” Ready In Process Done

109. 138 Example of a Definition of Ready Analyst – User story sufficiently defined and mapped from requirements Tester – Acceptance criteria developed Developer – User story is estimated and no known blocking dependencies exist within the sprint Definition of “Ready”

110. VisionandGoal

111. 140 A Typical Agile Pipeline Ideation Market Trends Prototypes Focus Groups User Experience Basic Workflows Vision Business Outcomes Release Timing and Goals Product Architecture Epics and Features Maturation User Story Decomposition User Story Maturation Acceptance Criteria Test Cases Dependencies Story Mapping Prioritization Epic Estimation Backlog Development Execution Sprint Planning Task Estimation Daily Standups Software Development Testing Burndowns Documentation Product Demos Retrospectives Current Sprint~2 Sprints Ahead>4 Sprints Ahead Marketing/Sales, Product Management, Product Owners, Architects Product Owners, Architects, Dev Leads, QA Leads, UX/Analysts Leads, UX/Analysts, Dev Team Members

112. 141 Vision Goal / Outcome Epic Feature Feature Story Story Story Story Story Feature Goal / Outcome Epic Feature Feature Requirements Breakdown Structure With Scrum, we refine requirements over time, from a high level Vision down to User Stories and tasks that can be executed in a Sprint. • At each level, items can break down further into siblings, so one Epic can become two. • The exact breakdown is often unclear; is this a Feature or an Epic? In reality, the exact breakdown is not important. • The names may also vary, so “User Story” or “Story” are often used interchangeably.

113. 142 1. Estimate relative level of effort for each feature o Takes into account complexity of work, effort, etc. o Uses relative units (e.g. A is half as hard as B) 2. Measure “Velocity” to set Team capacity o Takes into account external interruptions, technical surprises, developer skill level, domain knowledge, etc. o Work actually completed over time gives accurate data to determine capacity for a Team Agile Estimation Basics Velocity requires stability to be accurate.

114. 143 Example of a Definition of Done • Analyst – Working system reviewed and User Story accepted via Automated Test or Manual Inspection • Tester – Test cases pass. All critical and high severity bugs fixed and other bugs identified and tracked • Developer – Deployed to test environment and Code Review complete Definition of “Done”

115. 144 Story Estimate Status at End of Sprint As a Prospect, I can submit an application. 2 Pts* Complete As a Policy Holder, I can update my account information. 5 Pts Complete As an Account Representative, I can view a Policy Holder’s information. 8 Pts Complete As an Underwriter, I can approve or reject applications. 5 Pts 1 Pts Remaining Total Sprint Velocity 15 Pts Velocity Calculation * Pts = Story Points Next Sprint, 15 Pts would be our projected capacity.

116. 145 Metrics fall into two general categories: Business Value o ROI, IRR, NPV o % cycle time reduction o Customer satisfaction (NPS) Diagnostic o Velocity o Successful builds per iteration o Defects across iterations o Code coverage Defining Key Metrics in Agile Tips: • Measure outcome, not output • Measure only a few things • Ensure commonly understood operational definition and measurement plan • Target specific questions and audiences

117. 146 Planning Releases 1. Guess a starting velocity (14 in this case) 2. Choose which stories must exist to Release and see how many Sprints are needed, or… Work backwards from the Release date to fit as many high-value stories as possible 3. Adjust the scope within the Release as true Velocity becomes apparent Velocity = 14 points per Sprint Sprint 4 Story M 2 Story K 3 Story L 8 Sprint 1 Story A 5 Story B 3 Story C 5 Story G 1 Sprint 3 Sprint 2 Story D 2 Story E 5 Story F 2 Story H 8 Story I 5 Story J 5 Release 1

118. 147 Based on the velocity chart below, in what iteration can the business expect 33 more story points completed? Estimating Dates with Velocity Velocity stabilizes as business & technical domain knowledge increase and teams move from forming & storming to performing.

119. 148 If each sprint costs $20k, what would be the project cost at the end of iteration 15? Estimating Cost

120. 149 When you are mandated to use EVM Apply the 0/100 method to measure completion of Stories and Tasks. It is possible to maintain ANSI/EIA-748 reporting compliance • Replacing velocity with EV metrics • Creating measures of budgeted cost of work performed (BCWP) using "testable stories" • Establishing the Budgeted Cost of Work Scheduled (BCWS) baseline at the beginning of each iteration • Capturing Actual Cost of Work Performed (ACWP) through a time keeping system • Computing Cost Variance, Schedule Variance from the three base earned value metrics • Computing Estimate at Completion (EAC) and Estimate to Completion (ETC) from these base metrics as well. Agile EVM instead of Velocity 1. If you know why you use EVM now, the same applies to AgileEVM 2. Use the iteration as the unit for basing calculations

121. 150 • Review velocity and set Sprint capacity Identify anything unique about the coming sprint (vacation, holidays, etc.) • Select Sprint Goal (Optional) • Select top-priority User Stories from Product Backlog Select slightly more than capacity, aligned with Sprint goal as appropriate • Discuss User Stories to create Tasks & Acceptance Criteria • Estimate User Stories Base on individual task estimates, sticking to about 1-8 hours/task • Commit to User Stories Select until capacity is reached, with some backup stories discussed in case Team finishes early Sprint Planning Sample Agenda

122. Identifying&Modeling Users&Customers

123. 152 Prioritization and Socialization o Prioritize user types each release as you would functionality. Knowing high priority users helps you identify high priority functionality. o Post them in the area your team works to help team members empathize with target users and make better tactical design decisions. Focusing Testing & Evaluation o Identify user test subjects. o Identify alpha/beta test subjects. o Compare them with your eventual actual users to identify bad assumptions and to add new user constituencies. Applications of User Models

124. 153 Users interact directly with the system They are important to understand, because: • Knowledge of current usage patterns helps to design better, more usable systems. • Unsatisfied users will work around the system, nullifying its advantages and eventually eliminating it. Customers make buying or adoption decisions They are also important, because: • They have their own wish lists that may have little to do with their users’ needs. • They make the purchasing decisions, so if they aren’t happy, you won’t get in the door. Users vs. Customers

125. 154 Less detailed descriptions can also work Succinct User Roles Nurse Admitting New Patient to Ward Context Environment & basic responsibilities of the role Busy, noisy hospital. Characteristics Patterns of interaction, behaviors, and attitudes • Uses the application only several times a week. • Gets trained at in-service once a year. • Has access to peers to ask questions. Criteria Key objectives of the role “Get the data entered as quickly as possible without making any mistakes!”

126. 155 Personas take user roles one step further. o Represent our current or desired audience. o Provide a name, a face, and a description to a particular “user role.” Level of detail o Some believe in creating a small number of very detailed personas. These often over specify. o Lightweight personas will suffice for most situations. One Step Further - Personas “Extreme Character Personas will lead you to stories, you would be likely to miss otherwise” User Stories Applied by Mike Cohn

127. 156 Here are some example personas Example Personas Peter the Programmer “I’d like to get a better handle on test driven development and refactoring.” Peter’s company has just started using agile development. While he’s been a developer for a long time, he’s not used agile practices like TDD. David the Agile Developer “I've been using TDD, refactoring, and continuous integration for many years now. I want to see what's next.” David is a strong engineer that started with Extreme Programming practices about 2001. He’s proficient at most agile engineering approaches and always on the lookout for new cutting edge techniques. The other engineers in his department look to him for ideas and advice. Tara the Tester “How do I find time in an Agile process to test effectively?” Although Tara’s been a tester for a long time, she’s been working in an agile team for only a few months. Testing is a real challenge in an agile environment. Tara’s finding she needs to be part programmer to use the automated testing framework her company has adopted for acceptance tests. Some days Tara wishes her company would go back to waterfall development. Source: Based on “Personas” from Agile 2009

128. 157 A bit more detailed persona give personality to User Roles, helping the Team & Product Owner relate better to them. Personifying Your Users Night Nurse Robin Robin leaves for work at 6pm, after sleeping during the day. She works a 7pm-7am shift in Labor & Delivery, caring for prospective mothers and their babies. It is an uneven shift; sometimes chaotic and busy, sometimes slow. There are 16 other nurses in a given shift, and they coordinate their activities in a central room. Bad IT makes Robin grumpy. • Needs to be based on study of human behavior • Usability Testing • Observation • Interviews • Surveys • Empathy helps to guide design decisions • Should not be taken too literally

129. ScrumMaster

130. 159 A ScrumMaster: • Removes barriers between development and the customer so the customer drives development • Teaches customers how to maximize ROI and meet their objectives through Scrum • Enforces the values and practices of Scrum • Improves productivity in any way possible • Introduces engineering practices and tools to help ensure that each increment is potentially shippable ScrumMaster Responsibilities

131. 160 The ScrumMaster or Agile Project Manager wants one one-hour weekly status meeting instead of daily 15 minute stand-ups because one meeting is “more efficient.” What do you do? What do you do?

132. 161  Egoism: When a person acts to create the greatest good for himself or herself.  Utilitarianism: The idea that the moral worth of an action is determined solely by its usefulness in maximizing utility or minimizing negative utility.  Altruism: The opposite of egoism, a person’s primary purpose is to promote the best interests of others. Ethical Leadership Source: Based on Domains of Ethical Theories from Leadership Theory and Practice

133. 162  Listening  Empathy  Healing  Awareness  Persuasion  Conceptualization  Foresight  Stewardship  Commitment to the growth of people  Building community Servant-Leadership

134. 163 ScrumMaster Encourages: • Forthrightness • Blameless observations • Failing & learning fast ScrumMaster Discourages: • Defensiveness • CYA retrenching • Fear of failure Failure – End, or Means?

135. 164 • Ensure everyone is doing what they have agreed to do • Facilitate Scrum sessions • Look for ways to improve productivity and collaboration • Assist the Product Owner with the Product Backlog • Use all of your senses, including common sense, and remember that you have no authority Typical ScrumMaster Activities “A dead ScrumMaster is a useless ScrumMaster” - Ken Schwaber

136. 165 • Can a ScrumMaster also be a team member? • Can a ScrumMaster also be a product owner? • What potential issues might arise from these scenarios? Dialogue – Hats of the ScrumMaster

137. 166 What are the key differences between “traditional” PMs and “Agile” PMs or ScrumMasters? • What project activities does a traditional Project Manager typically handle? • How are these different from the activities required of a ScrumMaster? • Are there issues with wearing these two different hats? Group Discussion – PM vs. SM

138. 167 • Set the standard for the discussion. • Make the environment a priority. • Be mindful of timing issues. • Articulate the purpose of the discussion and its significance to the group. • Make use of various techniques/tools to keep the discussion moving when tension arises or discussion comes to a halt. • Try using an Agile game like “speedboat” • Pay attention to group behaviors. • Be relaxed and have a sense of humor to make sure discussions are enjoyable as well as educational. • Seek consensus with methods like dot voting or fist of five Facilitation Methods

139. 168 The goal is to identify factors that are preventing you from moving forward. In this case the sailboat represents your group or organization. The issues holding it back are symbolized by anchors. Anything propelling you forward is wind in your sails. Consensus Workshop Method “Sailboat” Based on Speedboat by Luke Hohmann of Innovation Games

140. 169 1. Build the foundation • Establish ground rules, roles and responsibilities • Frame the problem, constraints and desired outcome 2. Explore possibilities • Generate options • Solicit expert opinions • Storyboard potential solutions 3. Seek agreement • Show of hands • Roman vote • Fist of Five • Multi-voting Facilitating Group Decision Making

141. 170  Face the speaker  Maintain eye contact  Minimize external distractions  Respond appropriately  Focus solely on what the speaker is saying  Keep an open mind  Avoid letting the speaker know how you handled a similar situation  Wait until they finish to defend yourself  Engage yourself Active Listening

142. 171 Emotional Intelligence Unlike your Intelligence Quotient (IQ) which is pretty well fixed at an early age, your measure of Emotional Intelligence, or Emotional Quotient (EQ) can be easily developed throughout your life. Personal Competencies Social Competencies SELF-AWARENESS Knowing one's internal states, preferences, resources, and intuitions EMPATHY Awareness of others' feelings, needs, and concerns. MANAGING EMOTIONS Managing one's internal states, impulses, and resources. SOCIAL SKILLS Adeptness at inducing desirable responses in others. MOTIVATION Emotional tendencies that guide or facilitate reaching goals. Self Awareness Self- Management Social Awareness Relationship Management With Others WhatISeeWhatIDo With Me

143. 172 Five Levels of Conflict and Resolution Level 1: Problem to Solve •The normal conflict that occurs when team members have differences of opinions but can work through those for the greater good of the team and project. •Seek collaboration – Seek a win-win situation •Consensus. Learning where every team member’s head is with regard to the issue and, in time, arriving at a decision everyone can back. Level 2: Disagreement •Personal protection trumps collaboration. Language is guarded and open to interpretation. •Support – Empowering the other to resolve the problem. Level 3: Contest •The goal is to win. It is no longer about resolution but about coming out on top. •Accommodate – Yielding to the others view when the relationship is more important than the issue. Negotiate and get factual. Gather data to establish the facts. Level 4: Crusade •The battle lines have been drawn and each “side” does not believe the other side will change. •Focus on lowering the level of conflict. Use “shuttle” diplomacy and deescalate. Protecting one’s own group is the focus. Level 5: World War •It is not enough that the person wins but that they destroy the other person. •Do whatever is necessary to prevent people from hurting one another. Source: Lyssa Adkins Coaching Agile Teams

144. 173 • Analyze the situation. • Differentiate between wants and needs – both theirs and yours. • Focus on interests and issues rather than on positions. • Ask high and offer low, but be realistic. • When you make a concession, make clear you are yielding something of value. And don’t just give in. • Always make sure both parties feel as if they have won. This is a win-win negotiation. Never let the other party leave feeling as if he or she has been taken advantage of. • Do a good job of listening and articulating. Negotiations Source: PMI PMBOK® Guide 4th Edition Section G.8

145. 174 1. The ScrumMaster (SM) removes __________ between development and the customer. 2. __________would not have been a very good ScrumMaster. 3. __________ are altruists 4. With level 1 conflict, we seek __________ situation. 5. When facilitating a group, a ScrumMaster should ___________ a foundation, explore the possibilities, and __________ agreement. 6. You need to be __________of others' feelings, needs, and concerns to possess empathy. ScrumMaster Review a) Bill Lumburgh b)barriers c) build d)seek e) servant-leaders f) win-win g) aware 1(b)2(a)3(e)4(f)5(c)(d)6(g)

146. TheTeam

147. 176 Steps 1. Intro + Rules 2. 2 minute prep time 3. Get an estimate 4. Create velocity chart 5. 2 minute iteration 6. 1 minute improvement & new estimate 7. Repeat 5 times 8. Retrospective Collaboration Exercise Rules: 1. Start point = End point (person) 2. Process the most work possible 3. Balls must have air time when being passed 4. Balls may NOT be passed directly to your neighbor on the left or right 5. Balls must be touched by each and every person 6. Balls cannot be processed as one group (the bag/box) 7. Balls left on the floor at the end of an iteration are waste and will be subtracted from your production totalThank you Scott Dunn, Boris Gloger

148. 177  The inspect and adapt cycle can be used to improve a system of production.  A system has a natural velocity.  Velocity of a team stabilizes because of the team’s system and because the team learns how to work together.  Having a large team makes communication more difficult  If you want to go faster, you have to change the system. Exercise - What did we learn?

149. 178 Traditional Silos Customer BA Designer DeveloperPM Core Team (EXAMPLE) BA / Tester BA Tester Product Owner Developer Designer Developer / BA SM Release Manager Capacity Planner Prod. Architect Tech Ops Business Sponsor Risk Assessor Security Extended Scrum Team BAAnalysts DeveloperDeveloperDeveloper Designers TesterTesterTestersDevs The Core Team ideally consists of 5-9 dedicated members (7 +/- 2) The Extended Team may contain many additional members, each playing an important role, but they are typically not dedicated to the effort. Product Owner

150. 179 The analyst on the project wants to work one sprint ahead so that the analysis is ready when the programmers need it. The tech writers want to work one sprint behind so that they are “more efficient.” What do you do? Team of Specialists

151. 180 • Lazy Members – Not all team members will always be equal contributors. Focus on leveraging strengths, and encourage the team to help poor performers. • Consensus Quagmires – Group decisions can benefit from perspective and suffer from dilution. Use facilitation techniques to foster rapid, inclusive decision making. • Hero Culture – Teams must have shared goals, not be driven by individual desires. Roving leadership is an ideal state. Common Team Dysfunctions What are some other dysfunctions you’ve seen?

152. 181  Provide Feedback You can’t expect your team to operate in a vacuum.  Recognize Performance Give constructive feedback so they can meet your expectations. Reinforce what you like so they can continue to meet those expectations or exceed them. Team Motivation  Negotiate Recognize that some team members will not feel comfortable with some goals set for them. Negotiate realistic outcomes.  Persuade Get to know each of your team members personally and find out what motivates them.  Respect Respect is fundamental in any relationship. You will get the very best from people if you have mutual respect.

153. 182 Discuss answers to the following questions: • Have you ever been in a high-performance team? • What characterized that experience? • Could you replicate it effectively in Agile projects? Dialogue – High Performance Teams

154. 183 Self-organization refers to a process in which the internal organization of a system, normally an open system, increases automatically without being guided or managed by an outside source. Self Organization Source: Wikipedia

155. 184 Self-organizing teams: • Exhibit a high degree of collaboration • Operate with a high degree of trust and autonomy • Work towards high performance • Produce measurably great results • Are very fulfilling to work on Self Organizing Teams Self-Organizing Teams are Characterized by: • Small team size • Dedicated resources • Customer value orientation • Individual competence • Sustainable self-discipline • Intense collaboration • Easy information transfer • Low decision feedback time • Constant learning & interaction

156. 185 Team Diversity We want a broad model of diversity based on style, not just demographics • Change Readiness • Emotional Intelligence • Risk Aversion • Motivation • Work Style We want diversity as expressed in outer rings Values Beliefs Risk Aversion Emotional Intelligence Motivation Change Readiness Religion Communications Style Work Experience Geographic Location Family Status Education and Qualifications Age Gender Race Sexual Orientation Ethnicity Mental Abilities Physical Abilities

157. 186 The Team • Works cross-functionally (reduce handoffs !) • Shares roles to get the work done (i.e. generalizing specialist) Roles of the Team • A developer may write user documentation • A business analyst may perform testing • A tester may create graphics • Develops the detailed task list and the estimates • Volunteers for work (is not tasked) • Raises issues to the ScrumMaster • Assesses performance and makes process recommendations

158. 187 Self organizing principles guide a team so they can operate with minimal management control o As a team member, I will contact the ScrumMaster if I see a tweak that can be made to a feature, that will maintain it’s business value, while reducing time, cost or risk associated with implementing that feature o As a team member, when I complete my work, on a task, I will either help another team member, or start a new task, depending on what will most likely allow us to deliver the maximum value in a Sprint o As a team member, I will provide honest and open feedback to my peers, to the ScrumMaster, to the Project Manager, whenever that feedback will help the performance of the team Self Organizing Principles

159. 188 This is not a cross-functional team: Teams are Cross-Functional This is. Coding Testing Analysis Coding Testing Analysis Coding Testing Analysis Coding Testing Sprint 2Sprint 1 Sprint 3 Sprint 4 Sprint 5 Coding Analysis Testing Coding Analysis Testing Coding Analysis Testing Sprint 2Sprint 1 Sprint 3 Sprint 4 Sprint 5

160. 189 • Common area for collaboration o Open flow of information • Caves for privacy o Intense problem solving o Creative solitude o Private phone calls o Research o Rocking silently and weeping Caves and Commons Layout We all need a place to call home Whiteboard Covered Wall Burndown Chart Cubicles Cubicles Information Radiator

161. 190 • Information transfer maximized through collocation • Constant face-to-face communication and collaboration • Allows for Osmotic Communications • Self-organization & management facilitated by information radiators Shared Visual Workspace

162. 191 • Project Charter • Agile Manifesto • Key Contact Information • Project Calendar (vacations, etc.) • Objectives, Outputs & Outcomes • Success Sliders • Scope & Objectives Chart • Values/Rules of Engagement • Team Norms • System architecture diagrams • Information architecture diagrams • Burn Down Chart • Other metrics • Project Backlog and Timeline • Current Iteration Story Cards & Tasks (Tasks, WIP, To Verify, Done) • Risks & Issues Log • External dependencies/groups • Days left in Sprint/Iteration • Various team personalization stuff Information Radiator Examples Information radiators communicate what’s important for your project; each team has unique needs. Some examples:

163. 192 Team Room Examples 1. Portable easel 2. Smart board 3. Risks & Issues noted 4. Magnetic whiteboard 5. Plant needs water 6. Task board 7. Pair programming station 8. Status tracking by color 9. Nice chairs

164. 193 Documents Email & Portals Phone & Instant Messaging Video & Teleconferencing Face-to-face Communications Bandwidth Agile workspaces & information radiators are designed to reduce miscommunications, assumptions and disconnects by maximizing communications bandwidth. Unidirectional Activities Bidirectional Activities

165. 194 Isolated Scrum Teams Independent Daily Scrums. Distributed Scrum of Scrums Regular Scrum of Scrums. Integrated Scrum Team Team members split across locations. Distributed Daily Scrum Models Daily ScrumDaily Scrum New York Mumbai Daily ScrumDaily Scrum Daily Scrum Scrum of Scrums

166. 195 • Ensure more frequent feedback with shorter iterations • Use continuous integration, or at least regular builds • Send ambassadors, maintain site liaisons • Put phone/video/messaging communications technology to use • Use wikis for common project info • Use test scripts to understand requirements • Separate teams by functionality, not technical specialty • Expect more documents Check out Martin Fowler’s article http://martinfowler.com/articles/agileOffshore.html# UseContinuousIntegrationToAvoidIntegrationHeadaches Suggestions for Distributed Teams

167. 196 1. The ideal agile team size is ___________ to ___________ people. 2. Agile teams embrace the concept of ___________ instead of specialization. 3. Sharing functional responsibilities may require changes in ___________ policies and compensation. 4. Most of the team members should be ___________ time members of the team. 5. A focus on ___________ typically results in staff members working across teams and projects, which greatly reduces productivity. Team Review a) nine b)full c) utilization d)human resource e) five f) shared responsibility 1(e)(a)2(f)3(d)4(b)5(c)

168. The Scrum Process Initial Planning* Product Backlog Release Planning Sprint Planning Sprint Backlog Sprint Sprint Review Daily Scrum Sprint Retrospective

169. InitialPlanning

170. 199 Description Series of facilitated sessions to orient team members to the project’s business value and analytical background, the Agile process, and one another. Duration As long as it takes! Attendees Team, Product Owner, ScrumMaster, SMEs Initial Planning at a Glance Outputs •Project Orientation •Process Orientation •Team Orientation Initial Planning

171. 200 Agile Process Training Product Discovery o Agile Games with Customers o Collaborative Modeling Workshop o User Story Creation and Estimation o Product Backlog Prioritization o System Design o Architecture Spike Project Discovery o Sponsor Vision o Business Context, Key Metrics o Release Planning o Sprint One Planning Comprehensive Sprint 0 Process Discovery o Process Value Stream Map o Key Metrics Team Discovery o Team Norms & Core Hours o Iteration Structure o “Ready” Definition o “Done” Definition o Business value prioritization scheme o Team Structure (Core/Extended) o Stakeholder/Project Interactions Sample Sprint 0 Session(s) might include:

172. 201 1. Sprint 0 ___________ explicitly part of the scrum framework. 2. The product owner, ScrumMaster, key sponsors, key stakeholders, the ___________ and select subject matter experts participate(s) in the discovery sessions. 3. Business stakeholders and sponsors provide a clearly articulated vision with cascading ___________ so that we can ___________ measure future success. 4. In addition to providing context for the product, discovery provides context around the project, ___________ and team . 5. We avoid BDUF design. Instead we define just enough today to maximize the chance that we can deliver value tomorrow, recognizing that if we get too ___________, too early, we will likely over ___________ the team and get a less valuable product. Sprint 0 Review a) goals b) is not c) objectively d) process e) whole team f) constrain g) specific 1(b)2(e)3(a)(c)4(d)5(g)(f)

173. ProductBacklog

174. 203 Description List of desired functionality for project prioritized by business value by Product Owner. Key Characteristics • Contains requirements as “User Stories” • Near-term stories better defined Managed by Product Owner, ScrumMaster Product Backlog at a Glance Contains • Prioritized Product Backlog Items or User Stories • Rough estimates • [Optionally] Forecasted iteration boundaries • [Usually] Release Dates Product Backlog

175. 204 Adding User Stories • Anyone can suggest new User Stories • Product Owner prioritizes them Estimating & Elaborating • High-priority items are estimated and described most precisely, since they will be worked on first • Low-priority items are generally estimated and described coarsely Prioritizing • Prioritization is based primarily on Business Value Product Backlog Essentials # Backlog Item Estimate 1 Create login screen .5 … 20 Allow user to browse recently viewed items 8 … 60 Add personalization 30 (or so) High priority items are better defined Low priority items are often “epics”

176. 205 While business value should be the primary Product Backlog prioritization criterion in most cases, it isn’t the only one to consider. One might also factor in: o Risk o Complexity o Demand o Integration points from/to related projects or vendors Backlog Prioritization: A Closer Look Some Tips:  Create a prioritization scheme and Release Schedule that maximize the benefit realized from incremental releases.  Ensure that business needs and technical ones are balanced openly and jointly.

177. 206 1. The product backlog is essentially a ___________ to-do list. 2. A generic term for an item in the product backlog is ___________, a.k.a. PBI. 3. A PBI can be expressed in ___________ or other concise formats. 4. A PBI can be expressed in user story format even if it will take ___________ sprints to complete 5. PBIs can be at varying levels of detail, from an ___________ that can take several releases to finish, all the way down to a user story which can be completed in a single sprint. 6. High priority items are defined in ___________ than are lower priority items. Product Backlog Review a) epic or feature b) never-ending c) many d) more detail e) product backlog item f) user story 1(b)2(e)3(f)4(c)5(a)6(d)

178. ReleasePlanning

179. 208 Description Initial project planning session, to review initial Product Backlog and define Releases. Duration 2-4 hours Attendees Team, Product Owner, ScrumMaster Release Planning at a Glance Outputs • Release Plan • Refined Product Backlog Release Planning

180. 209 • Present Business Case & Desired Features Product Owner describes vision for product and initial set of User Stories • Estimate User Stories Team estimates high-level features in terms of story points or ideal delivery days • Prioritize User Stories Product Owner assigns priorities based on business value • Formulate Release Schedule Group User Stories into “minimum marketable feature sets,” set Release dates Release Planning Sample Agenda Some Tips:  This meeting should revolve primarily around the Release Schedule  Product Owners: Come prepared with an initially prioritized Product Backlog  Team: Come prepared with initial estimates for Product Backlog items

181. 210 Planning Releases with Story Maps Time Priority • Choose coherent groups of features that consider the span of business functionality and user activities • Support all necessary activities with the first release • Improve activity support with subsequent releases R1 S1 R1 S2 Provide Nurse ID Provide Patient ID Filter Records Sort Records Search Records Add Comment View History Enter Updates Search History Reference Validation Notify of Updates R2 S1 R2 S2 Access Record Review Record Update Record

182. 211 1. The ___________ brings ___________ product backlog items to the release planning session. 2. The ___________ provide(s) estimates in ___________ for the user stories and other product backlog items. 3. Based on story point estimates and velocity projections, the product owner can segment out which user stories will go into which ___________, and, for high priority, near term product backlog items, even which ___________. Release Planning Review a) clearly articulated b)story points c) sprint d)product owner e) whole team f) release 1(d)(a)2(e)(b)3(f)(c)

183. 212 What are some Visual Management Systems? • Outside of work, describe some visual control systems. • Are there opportunities to use them at home or work? Information Radiators - VMS

184. 213 Information Radiators 1-Jun 3-Jun 5-Jun 7-Jun 9-Jun 11-Jun 13-Jun 15-Jun 17-Jun 19-Jun 21-Jun 23-Jun 25-Jun 27-Jun 29-Jun Cumulative Flow, Burnups, Burndowns… are only the beginning

185. 214 Burndowns can provide context to make tough decisions at both the sprint and release level Burndowns to Provide Context Product Owner Speaking To date, we have completed feature 1 through feature 4. Unfortunately, we lost several key members of our team during iteration 6 and we are unlikely to get all planned features done for this release, unless we execute with perfection, which is unlikely. We will likely delay feature 9 and 10 until the next release, unless we make some tradeoffs. We already started discussions with sales and marketing and we may limit our work on feature 5 and 6 in the next Sprint. To Date Backlog Feature 1 Feature 2 Feature 3 Feature 4 Feature 5 Feature 6 Feature 7 Feature 8 Feature 9 Feature 10

186. 215 1. Release level burn downs track story points remaining for a release. Sprint burn downs have historically tracked ___________ remaining on ___________. Some teams today now burn down ___________ instead. 2. The primary purpose of the burndown is to help teams face reality so that they can make ___________. 3. Variations on a burn down can be used, such as ___________ or a ___________. Burndown Review a) burnup b) cumulative flow diagram c) hours d) story points e) tasks f) tradeoffs 1(c)(e)(d)2(f)3(b)(a)

187. SprintPlanning

188. 217 Description Meeting to elaborate, estimate and prioritize highest-value User Stories, creating Sprint Backlog. Duration 2-4 hours Attendees Team, Product Owner, ScrumMaster, SMEs Sprint Planning at a Glance Outputs • Estimated & Prioritized User Stories • Acceptance Criteria for User Stories • Sprint Backlog with Tasks Sprint Planning

189. 218 • Product Owners should arrive prepared to discuss top priority stories and ask any questions regarding alternate development paths • The Team may prepare estimates and questions about different development scenarios • Acceptance criteria should be jointly discussed and clarified • The length of the Sprint Planning session will generally be proportional to the length of the Sprint Sprint Planning Essentials

190. 219 1. The ScrumMaster should create a ___________ of events, holidays and team member schedules to support capacity planning and coordination 2. The ScrumMaster should evaluate velocity data to spot ___________. 3. At the beginning of sprint planning, team member availability for the sprint is confirmed. This information is combined with the historical velocity data to determine ___________ velocity for the sprint. 4. Team members ___________ for stories and tasks. ___________ are discussed to the extent necessary to allow the team to credibly commit to their completion within the sprint. 5. Some teams detail out all ___________ at Sprint Planning, others detail out just ___________ tasks, others create just a few chunky tasks, and some team don’t detail out tasks at all. 6. The ___________ determines which user stories it will commit to completing within the sprint. Sprint Planning Review a) trends b) target c) volunteer d) calendar e) high priority f) team g) tasks h) user stories 1(d)2(a)3(b)4(c)(h)5(g)(e)6(f)

191. SprintBacklog

192. 221 Description List of desired functionality for development in the current Sprint. Key Characteristics • Contains User Stories estimated at task level • Acceptance tests defined Managed by Team, ScrumMaster Sprint Backlog at a Glance Contains • Prioritized User Stories & their tasks • Task-level estimates • Information needed to understand the tasks Sprint Backlog

193. 222 Physical Task Boards

194. 223 1. ___________ user stories are selected from the product backlog for inclusion in the ___________. 2. The sprint backlog is essentially a detailed, short term, ___________ covering items for the ___________. 3. The sprint backlog may be stored in an electronic tool, a ___________ board, or both. 4. ___________ may, or may not, be stored in the sprint backlog. Sprint Backlog Review a) high priority b) physical c) sprint d) sprint backlog e) tasks f) to do list 1(a)(d)2(f)(c)3(b)4(e)

195. Sprint

196. 225 Description When the work gets done! Duration 1-4 weeks Key Characteristics • Isolated from further change • Requirements elaborated and refined • Work organized adaptively Involves Team, ScrumMaster, Product Owner, SMEs Sprint at a Glance Outputs • Potentially shippable functionality • Other items, as prioritized by Product Owner Sprint

197. 226 Effective Agile teams organize their work so that it flows: • Critical activities are never stalled by work on lower-priority activities (which may or may not arise in a future Sprint) • Decisions are made at the last responsible moment • Hand-offs are minimized in favor of synchronized collaboration Self-Organized Work Patterns Coding & Refactoring Business Analysis Testing Sprint 1 User Experience Architecture or Risk “Spikes” Sprint 2 Sprint 3

198. 227 Do your teams work like Agile teams? • Does collaboration happen often across roles? • Are activities assigned explicitly, or pulled based upon skill and capacity? • Do you have critical person dependencies? • Is communication between team members open and regular, or formalized and occasional? Dialogue – Teamwork

199. 228 1. The length of the sprint is ___________. 2. The sprint contains four ceremonies: ___________, ___________, ___________ and ___________. 3. Some teams ___________ their release and planning cycles. These teams often continue to use a fixed sprint cycle to provide a cadence for planning and retrospectives. 4. Backlog grooming (User Story maturity) for future sprints happens ___________. Sprint Review a) daily scrum b) decouple c) fixed d) sprint planning e) sprint retrospective f) sprint review g) during the current sprint 1(c)2(d)(a)(f)(e)3(b)4(g)

200. DailyScrum

201. 230 Description Brief, tightly facilitated status and risk management meeting for Team & Product Owner. Duration 10-15 minutes Attendees Team, ScrumMaster, optionally Product Owner and Interested Stakeholders Daily Scrum at a Glance Outputs • Risks & Issues • Informal meetings Daily Scrum

202. 231 • Reference specific tasks (at the task board if possible) • Record and Review Risks and Issues • Team members should speak to one another; this is an alignment tool, not an exercise to report to the boss Three Questions in Three Minutes What will you get done today?2 What did you get done yesterday?1 What’s in your way?3 Each participant answers 3 questions:

203. 232 Quick Quiz: Who maintains the team board? Parameters • Daily • 10-15 minutes • Everyone stands • Risks & issues noted • Not for problem solving! • Additional meet-ups arranged, often immediately following the Daily Scrum • Core team talks • Extended team listens Daily Scrum Essentials

204. 233 Core / Extended Team  ScrumMaster/ Agile PM  Product Owner  CIO  QA Manager  Tester  Business Analyst  Developer Daily Scrum – Quick Quiz Quick Quiz Who is allowed to talk at the Daily Scrum (Stand-up)?

205. 234 Some key benefits of the Daily Scrum include: • Shared language among team members • Real-time reallocation of resources Key Benefits of the Daily Scrum • Focus on value-creating activities • Clear, prioritized work plan for each day • Builds team identity and emotional commitment

206. 235 1. The daily scrum is often called a daily ___________. 2. The ScrumMaster can help make the daily standup effective by providing ___________ about schedules, days left in sprint, release date, etc., during the first 45 to 90 seconds. 3. The focus of the daily standup is to convey information so that the team can ___________ their collaboration. 4. The daily standup should last no longer than ___________ minutes. 5. At the daily standup the team members talk to ___________. 6. Detailed discussions and planning should occur ___________ the daily scrum. Daily Scrum Review a) 15 b)after c) co-ordinate d)context e) each other f) standup 1(f)2(d)3(c)4(a)5(e)6(b)

207. SprintReview

208. 237 Description Team demonstrates completed functionality to interested stakeholders, gathering feedback. Duration 2-4 hours Attendees Team, Product Owner, ScrumMaster, optionally Users & Interested Stakeholders Sprint Review at a Glance Outputs • New Features on Product Backlog • Reprioritized Product Backlog • Revised Team or Project Structure Sprint Review

209. 238 Present Completed User Stories Demo live functionality completed in prior Sprint; no decks! Record Customer & User Feedback Adjust Product Backlog o Remove completed functionality o Reprioritize unfinished functionality o Adjust priorities based on feedback Adjust Project Structure o Reformulate or resize the team o Schedule or reschedule a release o Decide to stop the project Sprint Review

210. 239 1. Another name for a sprint review is a sprint ___________ . 2. The sprint review should start with ___________ including a discussion on overall release progress, plans for the just completed sprint and identification of important tradeoffs to discuss. 3. The product owner and team members demonstrate ___________ built during the sprint. 4. The sprint review is a forum for the team and stakeholders to understand what has been done, what is left to be done, and what is likely to be done, so that they can make tradeoffs. These tradeoffs will impact the upcoming ___________ meeting. Sprint Demo Review a) context setting b) demo c) sprint planning d) working software 1(b)2(a)3(d)4(c)

211. SprintRetrospective

212. 241 Description Team continuous improvement session to reflect on project & process issues and take action as appropriate. Duration 30 minutes – 1 hour Attendees Team, ScrumMaster, optionally Product Owner Sprint Retrospective at a Glance Outputs • Process revisions • Project or Team structure revisions • Other improvement action items Sprint Retrospective

213. 242 The useful way to do “Lessons Learned:” • Periodically take a look at what is and is not working in your process • Typically 15–30 minutes • Done after every sprint • Whole team participates • Generates action items to continuously improve project execution Sprint Retrospective Essentials Working Well Not Working Well Automated unit testing 6am Daily Standup Customers highly satisfied Testing team availability Retrospectives have improved process Build cycle time Estimates are stabilizing Product Owner availability Action Items Set SLA with QA team PO delegates to proxy during Sprints 8am standup

214. 243 Sprint Retrospective

215. 244 Too often, companies focus too much attention on metrics like Team Performance and Team Efficiency, while ignoring metrics like Team Emotion or Happiness Sprint Retrospective Team Emotion

216. 245 1. The retrospective is often thought of as the ___________ part of the scrum process. 2. Effective retrospectives typically identify a ___________ of items to address. 3. At a minimum, a retrospective should identify ___________ and ___________. 4. Additional items to cover in a retrospective can include appreciations and ___________. 5. It is often helpful to collect ___________ feedback prior to the retrospective. Sprint Retrospective Review a) anonymous b)deltas c) learnings d)most important e) pluses f) small number 1(d)2(f)3(b)(e)4(c)5(a)

217. ThankYou!

218. 247 Contact Us for Further Information On the Web: LeadingAgile.com Facebook: /LeadingAgile Twitter: @LeadingAgile Posters with images from presentation TheCriticalPath.info & Pictofigo.com Last Updated: 2/27/2015

219. 248 Once this course has been completed: • If you currently have a PMI credential (PMP or CAPM), you can submit 21 PDUs directly to PMI • If you are pursuing the PMI-ACP and are applying for 21 Agile Contact Hours, you can submit this class under Agile Education • If this is a public class, LeadingAgile will send you an email within 24 hours with a link to a PDF version of this deck • LeadingAgile will send you a letter of completion within two business days Logistics & Expectations

220. 249 Hope is not a strategy Luck is not a factor Fear is not an option • At LeadingAgile, we are dedicated to solving the challenges associated with Agile in larger, more complex enterprises. • We provide Agile training and coaching, strategic enterprise Agile transformation consulting, and Agile project and portfolio management services. Specialties • Scrum, XP, AUP, RUP, Project Management, Program Management, Portfolio Management, Agile Training, Agile Coaching, Agile Consulting, Agile Transformation

PMI-ACP Training Deck

You are reading a preview.

Check these out next

PMI-ACP Training Deck

More Related Content

Slideshows for you (20)

Similar to PMI-ACP Training Deck (20)

Recently uploaded (20)