Skip to content

Instantly share code, notes, and snippets.

@KyleMit

KyleMit/PMI ACP Notes.md

Last active September 6, 2024 01:56
Show Gist options
  • Save KyleMit/eac17d8d7d4309fd38d25831c08ca7aa to your computer and use it in GitHub Desktop.
Save KyleMit/eac17d8d7d4309fd38d25831c08ca7aa to your computer and use it in GitHub Desktop.
Download ZIP
Raw
PMI ACP Notes.md

Instructor:

  • David Kearns, MBA, PMP, ACP
  • Working on VT Health Connect

Logistics

  • Start/Stop
  • Homework
    • 16 Page Scrum white paper
  • Breaks (approx every 30 min/hour)
  • Facilities
  • Email/Cell Phone Etiquette
  • WiFi
  • Net: BWConference
  • Pass: jammer03
  • Definition of Done (with each module)
    • Comfortable with Concepts/Principles Presented
    • Understand Key Terms within Module

Exam Overview:

  • Exam more conceptual than factual
  • Highly centered on Manifesto and Principles
  • not heavily based on numbers (i.e. net present value)

Modules

  1. Intstructor Introduction
  2. Course Introduction
  3. Exam Strategies
  4. Agile Principles and Mindset
  5. Agile Methodologies
  6. Value-Driven Delivery
  7. Stakeholder Engagment
  8. Team Performance
  9. Adapttive Planning
  10. Problem Detection and Resolution
  11. Continuous Improvement
  12. Course Summary and Final Exam

a) Daily Stand Up Review b)

People:

  • David
  • Stacy

Book

The PMI-ACP Exam: How To Pass On Your First Try, Iteration 2 (Test Prep series Cover

  • Chapter 1 - Understanding Agile
    • Methodologies
    • Traditional Waterfall Projects
    • The Agile Way
  • Chapter 2 - The PMI-ACP Exam
    • Background
    • What The Exam Tests
    • A Passing Grade
    • The Exam Material
    • Getting to the Test (the Application)
    • Requirements to Apply
    • Ongoing Education
    • Testing Environment
    • Time Limit
    • Question Format
  • Chapter 3 - The Agile Manifesto
    • History
    • The Agile Manifesto
    • How the Manifesto is Used
    • Agile Manifesto Values

Agile Manifesto

Manifesto

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Principles

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

  4. Business people and developers must work together daily throughout the project.

  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

  7. Working software is the primary measure of progress.

  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

  9. Continuous attention to technical excellence and good design enhances agility.

  10. Simplicity--the art of maximizing the amount of work not done--is essential.

  11. The best architectures, requirements, and designs emerge from self-organizing teams.

  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Triple Constraint

  • Scope
  • Time
  • Cost

SOV could use Master Service Agreement with multiple vendors

Exam Specifics

  • Book Focus
    • Focused on Passing the Exam
    • Memory Keys -> Triggers
    • Sample Questions
  • Your Obligations
    • Attend sessions
    • Focus
    • Do reading + HW
  • Qualifications
    • Secondary Degree
    • 2000 hrs on project team
    • 1500 agile experience
    • 21 contact hours of Agile Education
    • 8 + 8 + 5 at home
    • Bio on why you deserve PMI-ACP cert (through in buzz words)
  • Exam Specifics
    • 120 Multiple Choice
    • 20 Pre-test questions
    • 100 Scored questions
    • 3 hours time
    • Prometric Testing Facilities -
      • Frisk
      • 2 forms of ID
      • No Electronics -> Locker
      • Get whiteboard and a marker
        • Brain Dump onto Whiteboard?
  • What should you study
    • Test Booklet
    • Online Test
    • Material
      • Agile Principles
      • Value-Driven Delivery

Baseline Exam

Agile Principles & Mindset

  • As an Agile Certified Practitioner / Agile Coach / Scrum master
    • explore, embrace, and apply agile principles
    • adovcte for agile principles by modeling those principles
    • defend agile
    • ensure that everyone has a common understanding
    • support change at the system or organization level
    • enhance trust & transparency
      • information radiators
    • learn & improve
      • contribute to a safe and trustful team
    • experiment & discover
      • enhance creativity by experimenting
      • not necessarily have the answer right away
      • unknown -> spike
    • Work Together
    • Enable Self-Organizing
      • Encourage emergent leadership
    • Servant Leadership
      • How can i make you more successful
      • Lightning Rod

4 meetings/ceremonies within agile

requirement (SDLC) -> user story (agile)

Methodologies

Lean/XP/Scrum

Cross-functional Team vs. Cross-functional Team Members

Deming Cycle

by Dr W. Edwards Deming

AKA Deming circle/cycle/wheel, Shewhart cycle, control circle/cycle, or plan–do–study–act (PDSA)

  • Plan
  • Do
  • Check
  • Act

PDCA

Waterfall - 1 demming cycle Agile - lots of iterations

Agile Mindset

Role Traditional Agile
PM command and control part of the team peer/couch
Customer start & finish touch points sits at the table (daily)
Work/Tasks PM assigns Team manages collectively
Communication controlled; protocol RACI Chart out in open, radiators, team space
Decisions chain of command/authority team decides
Change influence/avoid or make money from it welcome & embrace for customer's advantage
Deliverables Owner Transition at close frequent, incremental, functional releases
Retrospectives end of project end of iteration; daily
Favors Anticipation Adaption

Delta - hedge against implementation talk - focus on passing exam - learning by putting in context is still helpful. not here to sell people the merits of agile

Information Radiator

https://www.atlassian.com/wallboards/information-radiators http://wiki.c2.com/?InformationRadiator https://en.wikipedia.org/wiki/Agile_software_development

  • examples
    • Kanban
    • Burndown

Terms

  • Iteration - timeboxed cycle with deliverables
  • Empirical
  • Incremental Release -
  • PDCA Cycle
  • Adaption

Questions

  • PM? Agile Coach
  • Change? Welcomes it!
  • Communications? Face to face

Agile Manifesto

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

History

On February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski, relax, and try to find common ground—and of course, to eat.

Mind Map (Mnemonic Device)

Values => Direction

Compass

Clock

  1. HP - Highest Priority
  2. WΔ - Welcome Change
  3. DF - Deliver Frequently
  4. TD - Together Daily
  5. MI - Motivated Individuals
  6. Fꟻ - Face to Face
  7. WS - Working Software
  8. ∞ - SD - Sustainable Development
  9. CA - Continuous Attention
  10. S - Simplicity (work not done)
  11. SO - Self Organizing
  12. RI - Regular Intervals

Exam Tips

  • focus on empowering "The Team"
  • run away from waterfall / traditional approach
  • focus on theory, not practice (not how we do it at work)
    • follow manifesto / scrum / xp / lean

Narrow choices by following value pairs (manifesto) & principles

Manifesto vs. Methodology

  • Agile = Values + Principles
  • Methodologies
    • Scrum / Kanban
    • eXtreme (XP)
    • Lean
    • Smaller
      • DSDM
      • RUP
      • Crystal Clear
      • AUP

Methodologies

Team Members

  • Team
    • Coach / Scrum Master
    • Customer / Product Owner
  • Senior Management

Manifesto Terms

  • Values
  • Methodology
  • Principles
    • Highest Priority
    • Working Software
    • Deliver Frequently
    • Simplicity
    • Welcome Change
    • Self Organizing
    • Responding to change
    • Sustainable Development
    • Work Together Daily
    • Customer Collaboration

Manifesto vs. Methodology

  • Scrum
  • XP
  • Lean

SCRUM

  • Roles
  • Artifacts
  • Ceremonies

Homework

The Scrum Guide Whitepaper

Scrum (Empiricism) Pillars

  • Transparency
  • Inspection
  • Adaptation

Product Backlog

DEEP (backlog)

  • Detailed Appropriately
  • Estimable
  • Emergent (re-orderable)
  • Prioritized

INVEST (user stories)

  • Independent
  • Negotiable
  • VVerifiable
  • Estimable
  • Sized appropriately
  • Testable

Iteration Size:

SCRUM - 30 days Extreme - 1 week

Ceremonies

  1. Sprint Planning
  2. Daily Scrum
  3. Sprint Review (Demo)
  4. Retrospective

Sprint Planning

Risk Adjusted Backlog

  • Normally prioritized by value
  • threats/riskiness may be prioritized down ↡
  • opportunities may be prioritized up ↑

Two Halfs

  • First - work with PO to decide what's in sprint
  • Second - just team - how are we going to get it done

Sprint Team

  • Scrum Master
    • Servant Leadership
    • Not PM
  • Sprint Team
    • Self-organizing, self managing
    • Cross-functional
    • No sub-teams, no titles, no titles
    • Accountable

Team Size

  • Minum 5
  • Maximum 9
  • Average 7 +/- 2
  • N * (N-1)/2 - number of relations in the group

Tools

  • Task Board
  • Burn-down chart

Work

  • Developing
  • Integrating
  • Reviewing, Adapt
  • Refactoring

Amazon's Jeff Bezos has a solution for this problem. He calls it the "two pizza rule": Never have a meeting where two pizzas couldn't feed the entire group.

User Story always delivered within iteration

Daily Scrum

  • Timeboxed (usually 15 minutes)
  • Inspect & Adapt
  • Everyone should answer three questions
    • What did you do yesterday
    • What are planning on doing today
    • What obstacles are you encountering
  • Product owner not required

Sprint Review

  • Half-day Meeting
  • Showtime
  • Key Stakeholders
    • Senior Mgmt
    • Product Owners
  • Team
  • User Sign off as part of Meeting (that's the clearance of UAT)
  • Delivers a Scrum Increment
    • Potentially shippable product increment
    • the sum of all the work involved in the sprint

Sprint Retrospective

  • 3 hour meeting
  • does not include product owner
  • "Inspect and Adapt"
  • Answer 3 Questions:
    • How did it go? (people, relationships, process, tools)
    • What worked?
    • What needs improvement?
      • Create improvement plan

SCRUM Roles

  • Sponsor/Customer
  • Stakeholder
  • Project Manager
  • Agile Coach
  • Team Member
  • Developer
  • Team includes Scrum Master

Scrum Artifacts

  • Product Backlog
  • Sprint Backlog
  • Increment
  • Tracking Charts

XP (eXtreme Programming)

  • XP takes beneficial software development practices to the EXTREME

Extreme programming was created by Kent Beck

12 Practices

  1. JAN - Planning Game (first)
  2. FEB - Small Releases (shortest month of the year)
  3. MAR - System Metaphor (march like a band)
  4. APR - Simple Design (April Showers Daily bring May flowers)
  5. MAY - Testing (You "may" pass)
  6. JUN - Pair Programming ("June Wedding")
  7. JUL - Collective Code Ownership (JULY -> Julius Caesar -> Ownership)
  8. AUG - Coding Standards (August -> congress -> groups makes laws)
  9. SEP - Sustainable Pace (SePtember)
  10. OCT - On-Site Customer (OCtober)
  11. NOV - Continuous Integration (November -> iNtegration)
  12. DEC - Refactoring (December -> D_cembere_)

Less Experienced Team just gets half:

  1. Planning Game
  2. Small Releases
  3. Testing
  4. Pair Programming
  5. Continuous Integration
  6. Refactoring

12 Practices

  • Planning Game
    • maximize value
      • writing user stories
      • estimating effort
      • risk analysis
      • commit to an iteration
    • Velocity
      • uses story points to estimate work load
  • Small Releases
    • Rapid delivery of value
  • System Metaphor
    • Substitute examples for system components
    • fosters creativity
    • avoids focused, closed minds
  • Simple Design
    • Efficient
    • Focus on today's needs
    • Easily Understood by entire team
    • incremental, continuous
  • Testing
    • Unit test each code component
    • code the unit test first
    • Test First & Test Often
    • Prevents Gold Plating
    • Bug? -> create test before fixing
  • Pair Programming
    • Provides fine-scale feedback
    • one drives, one observes
    • pilot / navigator analogy
    • more productive and efficient
    • Promiscuous Pairing - partners can change often
  • Collective Code Ownership
    • Entire team responsible for code
    • provides for shared understanding
    • peer pressure
    • fosters new ideas from all
    • needs a thorough test suite
  • Coding Standards
    • Provides shared understanding
    • Consistency and ease of refactoring
    • Foundation for collective ownership
  • Sustainable Pace
    • Provides for programmer welfare
    • No heroics needed
    • Steady intensity
    • Reduces defects due to stress and fatigue
  • On-Site Customer
    • Answer user story questions
    • faster feedback
    • available for decisios
  • Continuous Integration
    • New Code Integrated Immediately
  • Refactoring
    • Re-organize code for maintainabiliy, extensibility, alignment to test
    • Simplify where possible
    • Does not change functional behavior

5 Roles

  • Programmers
  • Tracker
  • Customer
  • Tester
  • Coach

X-Marks the Spot Mnuemonic

  • Programmer
  • Treasure Chest -> Tracker / Customer
  • Treasure Chest -> Tester / Coach

Lean

Started by Japanese Toyota car manufacturing

7 Principles

  1. SUN - See the Whole (Sunday -> see the whole day of the week)
  2. MON - Deliver as Fast as possible (Deliver earliest day in the week)
  3. TUE - Empower the Team (Tuesday -> Team)
  4. WED - Eliminate Waste (Wednesday -> Waste)
  5. THU - Build Integrity In (Thor's day -> Integrity)
  6. FRI - Amplify Learning (Fri and Fy - Don't Fry the Amplifier)
  7. SAT - Decide as Late as Possible (Sunday -> last day of the week)

Values -> Principles -> Methodologies (SCRUM, Lean, XP)

Terms

  • Empiricism
    • Transparency
    • Inspection
    • Adaptation
  • Lean
  • DEEP
    • Detailed
    • Estimable
    • Emergent
    • Prioritized

Value Driven Delivery

Project Selection / Chartering

  • Inputs
    • Business Priorities
    • Financial Measures
    • Compliance
  • Outputs
    • Project Proposals

Value Based Prioritization

Bigger is better

  • ROI - Return on Investment
  • PV - Present Value
  • NPV - Net Present Value (in today's dollars)
  • IRR - Internal Rate of Return

White Paper in Pages 81-87

Project Charter

  • The charter is the authorization for the PM by name to perform the project
  • Traditional and Agile Project!

Charter Contents pg. 59

  • Charter should be written as part of Iteration Zero (if it does not always exist)
  • It is created before significant actual project work commences
  • Created based on some need AND should explain the need
  • Signed by the performing org's senior mgmt
  • Names the authority to apply resources
  • Should include the high-level project requirements OR Critical success factors
  • Should include a high level milestone view of the project schedule
  • High level document that does not include project details
  • Includes summary-level preliminary project budget

Two Special Iterations

  • Iteration Zero - Planning
  • Final Iteration - Hardening

Agile or Traditional?

  • Agreement on Requirements / Scope
  • Certainty of Technology

Stacy Diagram

Stacy Diagram

  • Chaos - needs command and control
  • Simple - Building a house a hundred times - waterfall is fine
  • Complex - Agile Zone!

Brainstorming

  • Gather ideas from a group
  • Rapid-fire and inclusive
  • non-judgmental flow

evaluate, discuss, and group ideas afterward

Innovation games

  • 20/20 vision - relative estimating of difficulty of features using cards
  • The apprentice - observe other people doing process
  • Buy a feature - given a fixed amount of money, buy features
  • Product Box - physical representation of product - whatever you can put in the box
  • Prune the Product Tree - Group users stories on wall

Ranking Priorities by Value

MoSCoW Ranking Analysis

  • Must Have - Critical in this iteration
  • Should Have - important mabe later
  • Could Have - Desireable if time and money
  • Would Like - Not Necessary

Kano Analysis

Kano Analysis

Force Field Analysis

  • Ranked strength of forces, pro and con, related to a change
  • Supports an objective decision whether or not to proceed

Product Vision Statement

short, 30-second description - elevator pitch

For [who] that need [need], [product-it] provides [end-state]. It provides [valuable features]. It delivers [expected benefits].

Minimally Marketable Features (MMF)

the smallest set of functionality that adds customer or user value

Positive Value

Incremental Delivery

  • Deliver value more quickly
  • Responsiveness to change
  • Plan-Do-Check-Act
  • Priority - highest value first

Users Stories

  • often found on index card
  • back of card has acceptance criteria

"To me, this makes a lot of sense" clicks next slide

Process Tailoring

Fail fast; fail cheap

Non-functional requirements

  • Users Stories
  • Part of Definition of Done

SCRUM White Paper

http://scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf

empiricism - empirical process control theory

Pillars:

  • transparency
  • inspection
  • adaptation

Day 2

Stakeholder Engagement

Stakeholder Analysis

  • Chicken and the Pig - Ham and Eggs
    • Pig is committed, Chicken is merely involved

Stakeholders - anyone with an interest in the project

Pillars:

  • transparency / visibility
  • inspection
  • adaptation

User Stories

  • Requirement (business function)
  • Format
    • As A
    • I Want
    • So That
    • Acceptance Criteria
  • Write on Notecards
    • Passed around
    • Ranked
    • Stuck on wall

INVEST

INVEST (mnemonic)

  • Independent
  • Negotiable
  • Valuable (verifiable)
  • Estimable
  • Small (Sized Appropriately)
  • Testable

Epic

Large stories broken down and organized by functionality Epic can plan multiple iterations

Story Maps

Traditional Agile
WBS Story Map
Hi-Level Deliverable Epic
Work Packages Stories (INVEST)
100% Rule Not exact match
Decompose Disaggregation

Breakdown

Product Planning

Grooming - A working meeting / agreement between stakeholders

Product Planning - Persona

A fabricated, fictional user to bring a user story to life in a less general way (sometimes taken to the extreme)

  • Format
    • Name
    • Description
    • Photo?

Product Planning - Wireframes

  • Replacing heavy documentation, a high-level way to convey concepts
  • Non-working user interface design,
  • Showing major functions
  • No coding involved
  • May be hand drawn

Wireframe

Definition of "Done"

The team (include P.O.) must agree on exactly what done means

  • Passes acceptance
  • Meets coding standards
  • Signed off?
  • No technical debt?
  • No refactoring needed?

Kanban boards - limit WIP - Work in progress

Scrum Board vs Kanban Board

Scrum - constrained to an iteration Kanban - constraints work in progress (Japanese manufacturing term)

Terms

Disaggregation - break down an epic into smaller stories Grooming - refinement of backlog - risk adjusted

Team Performance

Coach Role

  • Counselor
  • Servant Leadership
  • Adaptive Leadership
    • Adapting to change! (often found in exam)
  • Build Team Unity
    • What's going to motivate the team?

Ground Rules

  • Expecations of team members
  • Typically unwritten
  • Clearly communicated
  • Project-wide, team-wide

Interpersonal (Soft) Skills

  • Emotional Intelligence (EQ)
  • Collaboration
  • Negotiation
  • Active Listening

Lea's Level of Conflict Model

  1. A Problem to Solve
  2. Disagreement (starts to become personal)
  3. Contest (people want to win)
  4. Fight/Flight (Crusade)
  5. Intractable Situation (WW - damage control)

Leas Model

Optimal Team Size
  • Agile doesn't scale well
  • Large projects/Teams -> divide up
  • Scrum Team Size: 7 +/- 2

Team Selection:

  • Willing to work as a team
  • Agile experience preferred
  • Skilled, self-directed, motivated
  • Open, transparent

Coaching the SO Team

  • Champion the process
  • Promote interacton
  • Get involved daily
  • Counsel team, not lead team
  • Assign nothing (exam tip)

Team Motivation

  • Sustain, hi-performance team
  • Support
  • Participation
  • Visibility

Team Participation Motivates

  • Each member contributes
  • Visible to team
  • Individual Motivation -> Team motivation

Colocation

Why?

  • Communication
  • Collaboration
  • Focus
  • Minimize Distractions
    • Heads Down Mode!

How?

  • One room, no barriers
  • Facing each other, same table
  • includes customer
  • see, hear, interact
  • No isolation, silos, or specialists
  • Wall space, information radiators

Protect the Team

Reduce distractions in order to establish a predictable outcome and optimize the value delivered

Two Primary Vehicles:

  • Scrum Master
  • Information Radiation

Osmotic Communication

  • Listening in
  • No headphones (Exam Tip)
    • Alternatively - Cone of Silence
      • Scheduled Talking Hours
      • Headphones allowed
      • No interruptions

Alistair Cockburn - Osmotic Communication

Communication Effectiveness

Communication Mediums

Colocation when Remote

  • Even more important
  • Invest in technology for closeness
    • webcam links
    • instant messenger
    • skype
    • audio/video conferencing
    • face-to-face
    • Groupware (e.g. google sheets)

Pros and Cons Team Space

  • Pros
    • Open
    • Small feedback loop
  • Cons
    • Noisy

Earned Value Management

  • Measure of how work and spending is progressing against the plan
  • Mechanics of Agile not exam-relevant
  • Based on Velocity (linear)
  • Tracked at the iteration level
  • Benefit? Organizational Compliance

Cross Functional: Teams vs. Individuals

Ace the PMI-ACP® exam

In order to promote collective ownership and accountability Agile team members are expected to be cross-functional. By cross-functional, we mean team members that are specialists in their areas, but still have adequate competencies at one or more other skills required for the project. In other words, they could be comfortable wearing multiple hats as required during different times of the project.

For Example:

  • a developer, in addition to doing design, coding and integration, could write the scripts for an automated regression test suite that runs in an auto-pilot mode
  • a business analyst, apart from his core duties of doing in-depth functional analysis and helping to write user stories, could also lend a helping hand in doing some exploratory testing

Cross-functional skills are invaluable for Agile project teams, because of the following benefits:

  • With cross-functional teams, it is easier to take shared ownership and group accountability for results.

-Ace the PMI-ACP® exam: A Quick Reference Guide for the Busy Professional 1st ed. Edition by Sumanta Boral (Author) Ace the PMI-ACP

**Ken Schwaber **

Ken Schwaber - Cross functional teams

Adaptive Planning

Discovery -> Product Backlog -> Delivery

Agile Discovery

  • finding out what is wanted
  • sometimes called the first step
  • Value Driven tactics like:
    • product vision statement
    • user stories
    • product backlog
    • value based prioritiziong

Dual Tracks Agile (on-going projects)

Continue discovering and delivering throughout project duration

Plan Levels with Evolving Detail

Cone of Uncertainty

Cone of Uncertainty

Rolling Wave Planning

  • Planning in stages, "waves"
  • More details closer in time
  • Natural Emergence of details

Progressive Elaboration

  • Features, requirements, stories, tasks, details, characteristics...
  • Not perfectly in focus in the beginning
  • revisting and refining
  • iterative and adaptive
  • responding to change

Waterfall AND Agile both Have:

  • Progressive Elaboration
  • Rolling Wave Planning
  • Project Charter

Product Roadmap

  • Shows planned release and respective features
  • It's what we intend, but it's not binding
  • Allows you to see the forest before the trees
  • 10,000 foot view

Release Planning

  • Group iterations into a product release
  • NOT a contract
  • Two special sprints in every release
    • Iteration - 0 - intial sprint to outlay work
    • Iteration - 1 to N
    • Iteration - H - hardening sprint

Agile Theme

  • Describes a high-level goal of an iteration
  • Added funtionality that builds toward the release
  • For example:
    • Reporting
    • Invoicing
    • Order Entry

Daily Stand ups

  • Peer-toPeer
  • Short, to the point
  • Entire Team
  • Same time, same place
  • Max 15 minutes (team size 5-9)
  • Not a status report
  • Not a place to SOLVE issues (RAISE Issues)
  • 3 questions:
    • What did you do yesterday?
    • What are you going to do today?
    • What are your obstacles?

Radiate Planning

  • Make planning activities visible and transparent by encouraging participation

Planning Levels

Plan Who What (you plan) Why
Product P.O. Value Need
Release P.O. When Fast Value
Iteration Team Effort/how Goal/Tasks

Spike

  • Decision time - which direction?
  • Small, quick, throw-away experiment to aid decision
  • Helps determines next step
  • Result of Spike (Deliverable) - Decision

Iteration Retrospectives

  • Lessons learned
  • immediate feedback; course corrections
  • what worked / what didn't

Adapt Estimates Iteratively

  • Ideal Time - if you could work, uninterrupted, with no breaks, what you would accomplish
    • Easier to estimate without uncertainty of overhead
    • reflects actual effor trather than duration
    • often used in agile estimating
  • Factor in Non-Ideal - Adjust capacity by incorporating maintenance and operations demands and other factors in order to create or update the range estimate (SM / PO)

Stories - Estimate with Point Tasks - Estimate points/hours + adjust for ideal time

Burn Rate

  • $$$ / time

  • How much money you're BURNing through over a fixed amount of time

  • Use to estimate costs

  • Amount of cost estimated over a period of time

    • Cost per iteration
    • Cost per week
    • Cost per month
    • Usually cost of team

Sizing Techniques

  • Relative Sizing - * Rank stories by relative effort
  • Affinity Estimating - Decide on a grouping technique (i.e. T-Shirt Sizes)
  • Planning Poker - Simultaneously reveal estimated points - explain high's and low's
  • Wideband Delphi
    • Buit ontop of Delphi Technique
      • "Blind"fold the judges to elimminate bias
      • All discuss together
      • estimatey separately
      • all plot range - discuss for consensus
      • repeat
      • individual estimates -> group wisdom

Parkinson's Law - Work expands so as to fill the time available for its completion

Timeboxing

  • Setting a fixed amount of time to work in a release
  • Can only deliver the value that is "Done"
  • Focus, urgency, and awareness

Kanban

Cumulative Flow Diagram

Cumulative Flow Diagram

Show WIP at any point in time - you'd like consistent heights for each section

Cycle Time - The amount of time to complete a feature or story

Velocity - The number of story points the team can deliver per iteration

  • Different for each team
  • Poitn are not equal across projects
  • XP - A pair cannto take more points thatn "done" in the previous iteration

Burn-Up Chart (shows done against the release plan)

  • Generally against longer time frame
  • Shows planned progress vs actual progress

Problem Detection and Resolution

Agile Smells

Escaped Defect - Defect introduced that was not caught during sprint

Root Cause Analysis

Ishikawa Fishbone diagram

Fishbone Diagram

Audit to minimize Cycle Time

Continuous Improvement (product, process, people)

Kaizen

Kaizen - a Japanese business philosophy of continuous improvement of working practices, personal efficiency, etc.

  • small changes
  • Continuous improvement
  • team focus amplifies effectiveness responsive to change

Stop Waste -> Stream Value

Value Stream Mapping

  • Present State
    • Value Stream
      • Process Stream
      • Process Stream
      • Process Stream
  • Gap Analysis ↓
  • Future State
    • Value Stream
      • Process Stream
      • Process Stream
      • Process Stream

UML Diagrams (like Business Process Mapping)

Ex.

  • Value Stream Mapping -> Buying Groceries
    • Process Stream -> Selecting a Cart
    • Process Stream -> Gathering Items
    • Process Stream -> Checking Out

Course Summary & Final Exam

Homework - After Course

  • Read Textbook
  • Finish Crossword Puzzle
  • Complete PMI-ACP Application
  • Memorize Brain Dump
  • Perform Practice Test 2 (Textbook)
  • Perform PMI-ACP Practice Test on InSite
    • Passing Grade ~70%
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment