Study Guide 2023+

agile

Warning: These notes are partial, ongoing, incomplete, and may contain typos/inaccuracies. (They are kept factually accurate, time permitting.)

They are being united from many disparate notes created in the past and the layout/organization will gradually improve with time!

Please view them on a computer as they are not optimized for mobile (although you can still view them on Mobile along with the Flashcards at your own risk)!

Topics and code examples are lazy-loaded and may require two-clicks from the TOC to correctly calculate the updated x,y coordinates (after rendering). Thanks!

PSPO I: Overview

Some notes I took before taking the Scrum.org - Professional Scrum Product Owner I (PSPO I) Exam.

Agile and Scrum

Typically encountered hand-in-hand (to the point that they are often used as synonyms):

The official Scrum Guide.

Not all Agile approaches involve Scrum, however (e.g. - Extreme Programming).

This approach contrasts with Project Management in the following ways:

Agile Manifesto

  1. Individuals and Interactions over Process and Tools
  2. Working Software over Comprehensive Documentation
  3. Customer Collaboration over Contract Negotiation
  4. Responding to Change over Following a Plan

The Scrum Values

  1. Courage
  2. Focus
  3. Commitment
  4. Respect
  5. Openness
  1. https://www.scrum.org/professional-scrum-competencies/understanding-and-applying-scrum-framework
  2. https://www.scrum.org/resources/scrum-values
  3. https://scrumguides.org/scrum-guide.html

PSPO I: Scrum

Scrum Framework

Often encountered in Software Development, can and is also used widely to manage and organize Work (of nearly any kind).

Scrum Pillars

Scrum Empiricism / Evidence Based Management:

  1. Measures, quantifies, observes Product value added, unrealized.
  2. Frequently inspects Product and market needs.
  3. Uses evidence to define Product Vision.

Pillars of this approach:

  1. Transparency - about their Work and Work Progress.
  2. Inspect - regularly review and inpsect their Work and Work Progress.
  3. Adapt - be flexible and willing to adapt their Work to fit changing demands.

Scrum Team

Core Team:

  1. Product Owner
    • Uses Empirical (Data Driven, Observational, Experimental) approaches to help determine what should or needs to be done on behalf of Customers and Stakeholders.
    • Product Vision determines
  2. Scrum Master
    • Ensures conformance to the Scrum Methodology.
    • Guides Stand.
  3. Scrum Developers
    • Build and create the Product.
    • Does not necessarily mean "Software Developer"!
    • Work collaboratively, cross-functionally, and as a team sharing their individual competencies/using their collective skills to accomplish Work.
    • A Product Owner can be a Scrum Developer too.
    • Typically, 5 (3-10 Developers).

Also:

  1. Stakeholders, Customers

Scrum Artifacts

Core Artifacts:

  1. Product Backlog - a Product goal that may cover multiple Sprints.
  2. Sprint Backlog - the Sprint goal.
  3. Increment - what the Scrum Team is working toward.
    • There is only one Increment at a time.
    • Any time a Product or Product Vision is updated, the Increment changes to that.
    • Excludes any previously completed work that isn't the most recent Product goal.

Also:

  1. User Stories - used to define and organize Work.
    • Are included in Product and Sprint Backlogs.
  2. Kanban Board - used to track and monitor Work Progress, Sprints.

Scrum Events

Event Description Present
Sprint Planning Sprint Goal is defined by Team. Items are selected for completion based on work estimates. Product Owner (Participates), Scrum Master (Participates), Developers (Participates), Stakeholders (Can Be Present)
Sprint Items selected from Team to be worked on toward the next Increment or Sprint Goal. Product Owner, Developers
Daily Scrum What got done, what will be done, what's blocking folks. Product Owner (Can Be Present), Scrum Master (Facilitates), Developers (Participates)
Sprint Review Demonstration of completed items. Product Owner, Scrum Master, Developers, Stakeholders
Sprint Retrospective Reviews what can be improved, what went well, what could have gone better, etc. Product Owner, Scrum Master, Developers
  1. Sprints
    • A Sprint goal is defined and the Scrum Team determines how best to accomplish that.
    • Work is organized into (typically) multi-week Sprints with each Scrum Developer commiting to an assigned/selected amount of Work.
    • Work commitments include important considerations like documentation, testing, deployments, compliance, coding, etc.
  2. Sprint Planning (Pointing, Grooming)
    • Creating User Stories - User Stories are defined from the perspective of a Stakeholder (or Developer) and assigned some number of Points indicating the relative effort or complexity to complete that Work.
      • Points are used to estimate the amount of Work Scrum Developers will commit to during a Sprint.
      • These need not correspond to a specific unit of time (although the number of Points is used to determine the amount of Work a Developer can or will commit to during a specified amount of time).
      • Specific Work items have Acceptance Criteria clearly defined to determine the status and completion of an item.
    • Backlog Refinement - Work is constantly being reviewed and new Work items are moved both into Backlog and current/future Sprints.
  3. Daily Scrum (Stand)
    • Guided by Scrum Master
    • Typically involves: What I got done yesterday, What I'm going to do today, and Here are my blockers succinctly conveyed in <3 minutes per Scrum Developer.
    • May be followed by some kind of impromptu meeting to address critical concerns and inform key Stakeholders (per Agile).
  4. Sprint Review (Acceptance)
    • Tasks and Sprints are reviewed to determine what was completed.
    • Now often involves a Presentation or Demostration of the completed Work to Stakeholders.
  5. Sprint Retrospectives (Retros)
    • Scrum Core Team discusses what went great, wrong, etc. during the last Sprint and determines ways to improve going forward.
  1. https://www.scrum.org/learning-series/scrum-team
  2. https://www.scrum.org/learning-series/scrum-events/

PSPO I: Definition of Done

Done in Scrum

  1. The definition of Done (within the context of Scrum) is: the Increment has achived a sufficient level of quality making it suitable for review from Stakeholders.
    • This level of quality should make it sufficient to release to Customers.
    • Furthermore, the aim is to create a Product that's truly beneficial to Customers not just something that's on time and on budget.
  2. The same Definition of Done should be used throughout the Product (e.g. - every Team working on the same Product Backlog.)
  3. The Developers determine what the Definition of Done should be (not the Product Owner).

So, the Definition of Done should be the primary barometer of Work completion. Generally, the Definition of Done should enable a Scrum Team to release the Increment to Stakeholders (and the Increment should be of value to them).

As one refines the Definition of Done, they should keep that guiding principle in mind.

Best Practices

  1. https://www.scrum.org/learning-series/definition-done/characteristics-of-the-definition-of-done/characteristics-of-a-good-dod
  2. https://www.scrum.org/learning-series/definition-done/characteristics-of-the-definition-of-done/dod-characteristics-to-avoid
  1. https://www.scrum.org/learning-series/definition-done/frequently-asked-questions-about-being-done/what-does-it-mean-to-be-done-in-scrum-
  2. https://www.scrum.org/learning-series/definition-done/characteristics-of-the-definition-of-done/characteristics-of-a-good-dod
  3. https://www.scrum.org/learning-series/definition-done/characteristics-of-the-definition-of-done/dod-characteristics-to-avoid

PSPO I: Timeboxing

Sprint Backlog

Remember:

  1. The Product Owner has the ultimate say over the Sprint Backlog.
  2. But Developers Point Work, can add to the Backlog, and are primarily responsible for determing Work Progress toward the Increment/Sprint goal.

Monthly Max Time Allocation

Scrum Event Max Time Allocation
Backlog Refinement No more than 10% of Developer capacity.
Sprint Planning 8 Hours Monthly for Sprints.
Sprint Review 4
Sprint Retrospective 3 Hours Monthly.

By following the above general guidelines, one will likely reduce the amount of time allocated to other, informal, adhoc meetings.

From a variety of sources including this very helpful Udemy course - Section 4. Scrum Events.

Cone of Uncertainty

Generally, the ability to accurately predict the cost of a change improves over time.

This is typically charted as a cone representing information entropy, risk, or uncertainty that narrows (representing the increased familiarity, predictive power, improved planning, tooling, etc. that reduces risk over time).

Udemy course - Section 6. Cone of Uncertainty

  1. https://www.udemy.com/course/product-owner-course/learn/lecture/21521908#overview

PSPO I: Topic Review

Role/Item Verb Item
Developers defines the Definition of Done
Developers manage the Sprint Backlog
Developers estimate all Backlog (Sprint, Product, Team) item efforts
Sprint Backlog items subset of the Product Backlog
The Product Backlog is the source of truth for Product requirements
Product Owner manage the Product Backlog
Product Owner determines Product releases
Stakeholders present at Sprint Planning, Sprint Review
The Sprint Goal provides guidance about the current Increment

Topics for review.

  1. Sprint Backlog items are a subset of all items in the Product Backlog.
    • In practice, Sprint Backlog is often kept distinct from Product Backlog. A Sprint Backlog is usually equivalent to some subset of a Team's Backlog. (In practice, a Team might be working on or at the intersection of multiple Products.)
    • Nevertheless, for the PSPO test / "Scrum Orthodoxy", the distinction above is important.
  2. Scrum Masters don't enforce the asking of Daily Scrum questions, they facilitate Daily Scrum (even when there are no action items).
    • In practice, this was not observed by nearly any team we had Scrum Masters for.
  3. The Product Owner is primarily responsible for the Product Backlog and the Developers primarily responsible for the Sprint Backlog.
    • With the permission of the Product Owner anyone can make changes to the Product Backlog.
  4. The Product Owner is primarily responsible for identifying and facilitating Stake Holder interactions (and using any feedback gained from Sprint Reviews to improve the Product, Product Vision, Product Backlog, etc.).
  5. Sprints can only be canceled if:
    • A Product Owner determines they should be.
    • When the Sprint Goal is obsolete, loses relevance, or no longer of value to the current Increment.
  6. Sprint Goals are defined and shaped by the entire Scrum Team.
  7. All time estimates (in all Backlogs) are primarily handled by the Developers (not the Product Owner).
  8. Release depends on:
    • "The customers that will be constrained by the new release" - how does a change hamper current use?
    • "The risk that the product’s value can get out of line with the marketplace" - how relevant/current/useful is the Product Increment
    • "The costs and benefits of the upgrade" - cost/benefit calculations.
    • "Can customers actually absorb the new release?" - can and will customers use the new Features/Version?
    • Is determined by the Product Owner (and informed by the Definition of Done).
  9. Multiple Teams working on the same Product should share the same Product Backlog, Definition of Done, and Product Owner. Additionally:
    • Multiple Teams completing their Sprints at the same time can and should combine their efforts into both a single Increment and Sprint Review.
    • If multiple Teams are working on integrations, it's the responsibility of the Developers to integrate resources (not the Product Owner).
  10. Sprints start immediately following the conclusion of a preceding one.
  1. https://scrumguides.org/scrum-guide.html

Agile: Misc. Topics

Kanban

Used with Agile, Scrum to assist with Backlog and Sprint management:

  1. Used to visualize a Scrum Sprint Backlog
  2. Scrum doesn't mandate a specific way to represent or track Work items.
  3. Usually depicted in columns where Work items move from left to right through various stages of completion.
  4. The right-most column represents those items that meet the Scrum Definition of Done.

DEEP

Used with Agile, Scrum to aid with Backlog management:

  1. Detailed (Appropriately)
    • Work items should be described and clear to a reasonable extent.
    • Developers should be able to complete the task with minimal obstruction, confusion, or need for additional explanation.
  2. Estimated
    • Uses some specified way to determine relevant estimates of time or complexity for meeting the Definition of Done.
  3. Emergent
    • Issues arise organically, sourced from many Stackholders, Developers
    • Dynamic, evolves
    • Ongoingly updated
  4. Prioritized
    • Uses some specified mechanism for clearly ordering Work items by ROI w.r.t. the Product Vision or Goal.
  1. https://www.atlassian.com/agile/kanban
  2. https://www.productplan.com/glossary/deep-backlog/
  3. https://www.testgorilla.com/blog/product-owner-interview-questions/