Jul 14

Scrum master vs Product owner

Both are Scrum accountabilities, but they focus on different things.

Product OwnerScrum Master
Focuses on what should be builtFocuses on how the team works effectively
Maximizes product valueImproves Scrum effectiveness
Manages and orders the Product BacklogCoaches the team in Scrum and Agile practices
Clarifies user stories and acceptance criteriaFacilitates events and removes impediments
Makes priority and scope decisionsProtects the team from process problems and disruption
Represents customer and business needsSupports the team, Product Owner, and organization
Accepts completed stories based on agreed criteriaDoes not normally accept or prioritize stories

Product Owner responsibilities

The Product Owner:

  • defines and communicates the Product Goal;
  • creates or clarifies Product Backlog items;
  • orders the backlog by value, risk, and dependency;
  • explains user stories and acceptance criteria;
  • decides what is most important;
  • works with customers and stakeholders;
  • reviews whether completed work meets expectations.

The Product Owner does not assign individual tasks to developers or tell them how to implement the solution.

Scrum Master responsibilities

The Scrum Master:

  • helps everyone understand and apply Scrum;
  • facilitates Scrum events when needed;
  • helps remove blockers;
  • coaches the team toward self-management;
  • helps the Product Owner manage the backlog effectively;
  • protects transparency and continuous improvement;
  • helps resolve collaboration and process problems.

The Scrum Master is not the team’s traditional manager and does not normally assign work.

During Sprint Planning

Product OwnerScrum Master
Explains priorities and desired outcomesEnsures the planning process is effective
Clarifies stories and acceptance criteriaHelps the team understand capacity and focus
Discusses the proposed Sprint GoalFacilitates discussion and collaboration
Answers business questionsHelps remove planning obstacles

Developers decide how much work they can take and how they will perform it.

Simple distinction

Product Owner: Are we building the right product?
Scrum Master: Are we using Scrum effectively to build it?

Teaching line

The Product Owner leads product value and priority. The Scrum Master leads process improvement, facilitation, and team effectiveness.

Jul 14

Scrum versus Kanban at scale

Yes—basic Scrum is primarily a team-level framework.

Scrum

Scrum explains how one cross-functional team manages work through:

  • Product Backlog
  • Sprint Planning
  • Sprints
  • Daily Scrum
  • Sprint Review
  • Retrospective
  • Product Owner, Scrum Master, and Developers

Scrum itself gives only limited detail about coordinating many teams.

Multiple Scrum teams can work on the same product, but they normally need additional coordination arrangements, such as:

  • a shared Product Goal and Product Backlog;
  • common integration standards;
  • cross-team dependency management;
  • synchronized Sprints;
  • Scrum of Scrums;
  • or a scaling framework such as SAFe, Nexus, LeSS, or Scrum@Scale.

Kanban

Kanban can be used at several levels:

  • one individual;
  • one Agile team;
  • multiple teams;
  • a department;
  • a program or value stream;
  • a portfolio.

For example, a multi-team Kanban board might show:

Requested → Analysis → Team Development → Integration → Validation → Released

Different teams may be responsible for different parts of that flow.

However:

A Kanban board alone does not automatically coordinate multiple teams.

The organization still needs:

  • shared workflow policies;
  • dependency visibility;
  • WIP limits;
  • clear ownership;
  • integration agreements;
  • escalation mechanisms;
  • regular coordination meetings.

Scrum versus Kanban at scale

QuestionScrumKanban
Primary focusTeam delivery within SprintsFlow of work through a system
Usually starts atTeam levelTeam or workflow level
Can involve multiple teams?Yes, with additional coordinationYes, through a shared end-to-end workflow
Main control mechanismSprint timebox and Sprint GoalPull system and WIP limits
Common metricsVelocity, Sprint burndownLead time, cycle time, throughput, WIP
Does it fully solve enterprise coordination?NoNo

In SAFe

SAFe provides the layer for coordinating multiple teams.

Each team may use:

  • SAFe Scrum, or
  • SAFe Team Kanban.

Then the Agile Release Train coordinates them through:

  • PI Planning;
  • PI Objectives;
  • Program Board;
  • cross-team dependencies;
  • ART Sync;
  • System Demo;
  • shared cadence;
  • RTE facilitation;
  • program-level risk management.

GlobalZipCart example

Each GlobalZipCart feature group can operate as a Scrum team:

  • Team 1: User Accounts
  • Team 2: Catalog and Search
  • Team 3: Cart and Checkout
  • Team 4: Payments and Fraud
  • Team 5: Orders and Fulfilment
  • Team 6: Reviews and Recommendations

Their individual Sprint Planning is Scrum.

When all six teams coordinate their four-sprint plans, dependencies, risks, and PI Objectives, that is the SAFe multi-team layer.

Teaching line

Scrum mainly manages one team. Kanban manages flow and can span one or many teams. SAFe provides structured coordination across multiple Scrum or Kanban teams.

REF: AI Tools/ChatGPT as is

Jul 14

LPM — Lean Portfolio Management

LPM — Lean Portfolio Management

Lean Portfolio Management is the SAFe approach for connecting an organization’s strategy and funding to the work performed by value streams and Agile Release Trains.

Team level asks: What stories should we complete?
ART level asks: What features should the teams deliver during the PI?
Portfolio level asks: Which major initiatives should the organization fund, and why?

LPM operates at the portfolio level, above individual Scrum teams and ARTs.

Three main responsibilities

LPM areaWhat it does
Strategy and investment fundingDefines portfolio vision, strategic themes, priorities, and budget allocation
Agile portfolio operationsCoordinates value streams, ARTs, dependencies, and portfolio execution
Lean governanceMonitors spending, outcomes, risks, compliance, and performance without excessive bureaucracy

Your SAFe material presents these as the three central areas of LPM.

Traditional funding vs Lean funding

Traditional approach

An organization may fund temporary projects:

“Approve $3 million for the WWShopCart international-shipping project.”

When the project ends, people may be reassigned and another approval process begins.

Lean portfolio approach

LPM commonly funds a long-lived value stream:

“Allocate capacity and funding to the WWShopCart Customer Purchase Value Stream.”

That value stream can continuously prioritize the most valuable epics and features instead of requesting a new project budget for every change.

Portfolio Kanban

LPM can use a Portfolio Kanban to manage large initiatives called epics.

Typical flow:

Funnel → Reviewing/Analyzing → Portfolio Backlog → Implementing → Done

StageMeaning
FunnelNew ideas and opportunities are captured
AnalyzingBusiness value, cost, risk, feasibility, and strategic alignment are examined
Portfolio BacklogApproved epics wait for available capacity
ImplementingValue streams and ARTs are actively delivering the initiative
DoneThe epic has produced and validated its intended outcome

WWShopCart example

Suppose the organization is considering these portfolio epics:

  1. Launch WWShopCart in Canada
  2. Add international shipping
  3. Introduce AI-based recommendations
  4. Add cryptocurrency payments
  5. Meet new privacy and security requirements

LPM would ask:

  • Which epics support the company’s strategy?
  • What customer or business value will they create?
  • What are their costs and risks?
  • Which value streams and ARTs will deliver them?
  • Is sufficient capacity available?
  • What should be funded now, postponed, or rejected?
  • How will success be measured?

LPM might decide:

International shipping and privacy compliance are funded first because they are necessary for the global launch. Cryptocurrency payment is deferred because it has lower immediate value and higher risk.

LPM versus PI Planning

Lean Portfolio ManagementPI Planning
Portfolio-level decision-makingART-level planning
Chooses and funds major initiativesPlans features and objectives for the next PI
Longer-term strategic perspectiveUsually covers the upcoming PI
Focuses on value streams and epicsFocuses on teams, features, dependencies, and risks
Asks, “Are we investing in the right things?”Asks, “How will the teams deliver them together?”

Teaching line

LPM decides where the organization should invest. PI Planning decides how the ART will coordinate delivery of that investment.

LPM: Strategy, Investment, and Portfolio Governance

This phrase summarizes what Lean Portfolio Management does at the organizational level.

1. Strategy

LPM ensures that major initiatives support the organization’s goals.

It asks:

  • What outcomes does the organization want?
  • Which customer needs or market opportunities matter most?
  • Which epics support the strategic themes?
  • What should be prioritized or postponed?

WWShipCart example:

The strategy may be:

Launch a secure international e-commerce platform supporting multiple currencies, languages, and shipping regions.

Therefore, international payments and shipping may receive higher priority than optional cosmetic enhancements.

2. Investment

LPM decides where money, people, and capacity should be allocated.

It asks:

  • Which value streams should receive funding?
  • How much capacity should be assigned to features, technical work, compliance, and innovation?
  • Which initiatives provide the greatest value?
  • Should an epic be funded, delayed, or stopped?

WWShipCart example:

The organization might allocate investment to:

  • customer purchasing capabilities;
  • payments and fraud prevention;
  • order fulfilment;
  • platform security and infrastructure.

LPM normally focuses on funding long-lived value streams, rather than approving every small project separately.

3. Portfolio governance

Portfolio governance ensures that investments are controlled responsibly and produce the expected outcomes.

It includes:

  • monitoring spending;
  • reviewing business outcomes;
  • managing portfolio-level risks;
  • ensuring security and regulatory compliance;
  • measuring progress;
  • stopping or changing initiatives that are not producing value.

Governance does not mean heavy bureaucracy. In Lean management, governance should be:

Lightweight, evidence-based, and focused on outcomes.

WWShipCart example:

Leadership may review:

  • whether the international launch remains on schedule;
  • whether payment-security requirements are satisfied;
  • whether investment is producing customer value;
  • whether major risks require funding or scope changes.

Simple comparison

LPM responsibilityMain question
StrategyAre we pursuing the right goals?
InvestmentAre we funding the right work?
Portfolio governanceAre we controlling investment and achieving the expected outcomes?

Teaching line

Strategy decides where the organization wants to go. Investment provides the resources to get there. Portfolio governance ensures the organization remains responsible, compliant, and focused on results.

Jul 14

Story points: Fibonacci, Poker, Agile

Story points

Story points estimate the relative size of a user story.

They consider:

  • effort,
  • complexity,
  • uncertainty,
  • technical risk,
  • dependencies.

Story points do not directly mean hours or days.

A 5-point story is expected to be larger or more uncertain than a 3-point story, but it does not necessarily take exactly five hours or five days.

Fibonacci scale

use the Fibonacci-style sequence:

1, 2, 3, 5, 8, 13

The gaps become larger because uncertainty increases with larger work.

PointsTypical interpretation
1Very small, clear, little risk
2Small and well understood
3Moderate effort
5Larger, some complexity or uncertainty
8Complex, risky, or dependent on other work
13Very large or unclear; may need to be split

Example

For the Cart and Checkout feature:

User storyPossible estimateReason
Remove an item from the cart2Small, clear behavior
Update item quantity3Includes validation and total recalculation
Apply a promo code5Requires business rules and error handling
Complete checkout8Multiple steps and cross-team dependencies
Build the complete cart-and-checkout flow13Too broad; should probably be split

Planning poker

Planning poker is a collaborative estimation technique.

Each team member privately chooses a Fibonacci card for the story. Everyone reveals their estimate at the same time.

Process

  1. The Product Owner explains the user story and acceptance criteria.
  2. Team members ask questions.
  3. The team discusses effort, complexity, uncertainty, and dependencies.
  4. Each member privately selects a point value.
  5. Everyone reveals their value simultaneously.
  6. The highest and lowest estimators explain their reasoning.
  7. The team discusses the differences.
  8. Everyone estimates again.
  9. The process continues until the team reaches consensus or close agreement.
  10. The final estimate is recorded in Jira.

Example planning-poker discussion

Story:

As a customer, I want to apply a promotional code so that I can receive a discount.

Initial estimates:

  • User A: 3
  • User B: 5
  • User C: 8
  • User D: 5

Discussion:

  • The User choosing 3 assumed only one simple code.
  • The User choosing 8 considered expiration dates, usage limits, invalid codes, and payment integration.
  • After reviewing the acceptance criteria, the team agrees that the story has more complexity than first assumed.

Final estimate:

5 story points

Important teaching points

  • Story points are assigned by the team, not only by the Product Owner.
  • Planning poker is not a simple average.
  • The goal is shared understanding, not mathematical precision.
  • A large disagreement often reveals hidden assumptions.
  • A 13-point story should usually be reviewed and possibly divided into smaller stories.
  • Teams should not compare their story-point scale with another team’s scale.

Teaching line

Fibonacci gives the team an estimation scale. Planning poker gives the team a method for reaching a shared estimate.

REF: AI Tools/ChatGPT

Jul 13

How to Prioritize all the stories using MoSCoW

• Prioritize all the stories using MoSCoW

You assign every user story one of four MoSCoW priorities and then arrange the Jira backlog from highest to lowest priority.

PriorityMeaningGuiding question
Must HaveEssential for the feature or first usable releaseWill the feature fail or become unusable without this story?
Should HaveImportant, but a temporary workaround is possibleIs it valuable but not essential for the first release?
Could HaveDesirable enhancement with lower business impactCan it be removed with limited impact?
Won’t Have this timeExplicitly excluded from the current four-sprint roadmapCan it be deferred to a later release?

How you should prioritize

They should evaluate each story using:

  1. Business value — Does it directly support the customer’s main goal?
  2. Dependency impact — Do other stories or teams need it first?
  3. Risk reduction — Does completing it early reduce technical or integration risk?
  4. Legal, security, or compliance need — Is it mandatory?
  5. MVP importance — Is it required for a basic end-to-end customer journey?
  6. Time and capacity — Can it realistically fit within the four sprints?

GlobalZipCart example: Cart and Checkout

User storyMoSCoW priorityReason
Add a product to the cartMustThe cart cannot function without it
Update product quantityMustEssential cart-management capability
Remove an item from the cartMustRequired for a usable cart
Complete checkoutMustRequired to create an order
Calculate shipping and taxMustNeeded for an accurate order total
Apply a promotional codeShouldImportant business feature, but checkout can work without it
Save cart for laterShouldValuable, but not required for the initial purchase flow
Display product recommendations in the cartCouldHelpful enhancement, not essential
Create multiple named shopping cartsWon’t this timeCan be deferred to a later release

Important clarification

Must Have does not mean “I really want it.”

A Must Have story should pass this test:

“Without this story, can the assigned feature still deliver its essential purpose?”

If the answer is no, it is probably Must Have.

Jira backlog order

Within Jira, you should normally arrange stories in this order:

Must → Should → Could → Won’t Have this time

Within each category, they should further order stories by dependency, business value, risk, and logical delivery sequence.

For example, a foundational API needed by three other teams should appear above a user-interface enhancement, even when both are classified as Must Have.

Teaching line

MoSCoW identifies how necessary each story is. Backlog ordering determines which story should be delivered first.

Jul 13

ValidateNotNullOrEmpty

[ValidateNotNullOrEmpty()] is a PowerShell parameter-validation attribute.

It rejects values that are:

  • $null
  • An empty string: ""
  • An empty collection

Example:

function Show-ComputerName {
    param(
        [Parameter(Mandatory)]
        [ValidateNotNullOrEmpty()]
        [string]$ComputerName
    )

    Write-Output "Computer name: $ComputerName"
}

Valid call:

Show-ComputerName -ComputerName "PC01"

Output:

Computer name: PC01

Invalid empty value:

Show-ComputerName -ComputerName ""

Invalid null value:

$name = $null
Show-ComputerName -ComputerName $name

Why combine it with Mandatory?

[Parameter(Mandatory)]

requires the parameter to be supplied.

[ValidateNotNullOrEmpty()]

requires the supplied value to contain something.

They are commonly used together:

param(
    [Parameter(Mandatory)]
    [ValidateNotNullOrEmpty()]
    [string]$Path
)

Array example

function Test-Servers {
    param(
        [Parameter(Mandatory)]
        [ValidateNotNullOrEmpty()]
        [string[]]$ComputerName
    )

    foreach ($computer in $ComputerName) {
        Write-Output "Testing $computer"
    }
}

Call:

Test-Servers -ComputerName "PC01", "PC02"

Important limitation

A string containing only spaces is not technically empty:

Show-ComputerName -ComputerName "   "

To reject whitespace too, use:

[ValidateScript({
    -not [string]::IsNullOrWhiteSpace($_)
})]
[string]$ComputerName

A simple definition:

[ValidateNotNullOrEmpty()] ensures that a parameter value is not null, blank, or an empty collection.

Jul 13

Write-Error

Write-Error in PowerShell

Write-Error writes an error message to PowerShell’s error stream.

By default, it creates a non-terminating error. That means PowerShell displays the error, but usually continues with the next command.

Write-Error "The file could not be found."

Write-Output "The script continued."

Typical result:

Write-Error: The file could not be found.
The script continued.

Make it terminating

Use:

-ErrorAction Stop

Example:

Write-Error "The file could not be found." -ErrorAction Stop

Write-Output "This line will not run."

Now the error stops normal execution.

Use with try/catch

try {
    Write-Error "The server is unavailable." -ErrorAction Stop
}
catch {
    Write-Warning "The error was caught."
    Write-Warning $_.Exception.Message
}

Possible output:

WARNING: The error was caught.
WARNING: The server is unavailable.

Without -ErrorAction Stop, the catch block normally does not run because Write-Error is non-terminating by default.

Inside a function

function Get-LabFile {
    param(
        [string]$Path
    )

    if (-not (Test-Path -Path $Path)) {
        Write-Error "The file '$Path' does not exist."
        return
    }

    Get-Content -Path $Path
}

Call:

Get-LabFile -Path ".\missing.txt"

Error details

Write-Error can provide more structured information:

Write-Error `
    -Message "The configuration file is missing." `
    -Category ObjectNotFound `
    -ErrorId "ConfigFileMissing" `
    -TargetObject ".\config.json"

This creates an error record containing:

  • Message
  • Error category
  • Error ID
  • Target object

$Error

Errors written by Write-Error are normally stored in the automatic $Error variable.

Write-Error "Testing error storage"

$Error[0]

$Error[0] is the most recent error.

Write-Error versus throw

Write-Error "A problem occurred"
  • Non-terminating by default
  • Usually continues
  • Can be changed with -ErrorAction Stop
throw "A serious problem occurred"
  • Terminating
  • Stops execution immediately unless caught

Write-Error versus other output commands

CommandPurpose
Write-OutputSends normal data to the success pipeline
Write-WarningDisplays a warning
Write-VerboseDisplays detailed information when -Verbose is used
Write-ErrorWrites an error record
throwCreates a terminating exception

A useful rule:

Use Write-Error when an operation has failed but the caller may decide whether execution should continue. Use throw when the operation cannot safely continue.

Jul 13

Terminating error vs non-terminating error

Terminating error vs non-terminating error in PowerShell

Non-terminating error

A non-terminating error reports a problem but allows PowerShell to continue running the remaining commands.

Example:

Get-Content -Path ".\MissingFile.txt"
Write-Output "The script continued."

Possible output:

Get-Content : Cannot find path '.\MissingFile.txt' because it does not exist.
The script continued.

The file-reading command failed, but PowerShell still ran the next line.

Common examples include:

Get-Content ".\MissingFile.txt"
Get-Item ".\MissingFolder"
Write-Error "A problem occurred"

By default, many PowerShell cmdlets generate non-terminating errors.

Terminating error

A terminating error stops the current operation or script block. PowerShell does not continue normally unless the error is caught.

Example using throw:

throw "The configuration file is invalid."

Write-Output "This line will not run."

The second command does not run because throw creates a terminating error.

Another example:

$result = 10 / 0
Write-Output "Finished"

Division by zero produces a terminating error.

Main difference

FeatureNon-terminating errorTerminating error
Displays an errorYesYes
Continues to the next commandUsually yesNo
Automatically activates catchNoYes
Can be converted using -ErrorAction StopYesAlready terminating
Typical sourceCmdlet failurethrow, runtime failure, or -ErrorAction Stop

Why try/catch sometimes does not work

Consider:

try {
    Get-Content -Path ".\MissingFile.txt"
}
catch {
    Write-Output "The error was caught."
}

You might expect catch to run, but Get-Content normally produces a non-terminating error.

Therefore, PowerShell displays the error but may not enter the catch block.

To make it catchable, add:

-ErrorAction Stop

Correct version:

try {
    Get-Content -Path ".\MissingFile.txt" -ErrorAction Stop
}
catch {
    Write-Output "The file could not be read."
}

Now the non-terminating error is converted into a terminating error, so catch runs.

Full example

try {
    Write-Output "Trying to read the file..."

    $content = Get-Content `
        -Path ".\MissingFile.txt" `
        -ErrorAction Stop

    Write-Output "The file was read successfully."
}
catch {
    Write-Warning "The file could not be read."
    Write-Warning "Reason: $($_.Exception.Message)"
}
finally {
    Write-Output "The operation is complete."
}

Expected output:

Trying to read the file...
WARNING: The file could not be read.
WARNING: Reason: Cannot find path ...
The operation is complete.

The finally block runs whether the operation succeeds or fails.

ErrorAction values

Many cmdlets support the common parameter -ErrorAction.

Get-Content ".\MissingFile.txt" -ErrorAction Continue

Common choices:

ValueBehaviour
ContinueDisplay the error and continue; default behaviour
SilentlyContinueHide the error and continue
StopConvert the error into a terminating error
InquireAsk the user what to do
IgnoreHide the error and do not add it to $Error

For exception handling, the most important one is:

-ErrorAction Stop

Write-Error compared with throw

Write-Error

By default, it creates a non-terminating error:

Write-Error "The server was not found."

Write-Output "The script continued."

To make it terminating:

Write-Error "The server was not found." -ErrorAction Stop

throw

throw creates a terminating error:

throw "The server was not found."

Use throw when the script cannot safely continue.

Simple rule

A non-terminating error reports a problem and usually continues. A terminating error stops normal execution and can be handled by try/catch.

When using a cmdlet inside try, commonly write:

try {
    Some-Command -ErrorAction Stop
}
catch {
    Write-Warning $_.Exception.Message
}

Jul 12

Was quality truly built in???

Answer: Probably no — quality was not truly built in.

The team may have done some testing, but the result shows that quality was not built into the full process.

Why?

Because:

EvidenceWhat it suggests
Checkout crashes 40% of the timeCritical functionality was not properly tested.
Password reset failsImportant user flow was missed.
Buttons do not respond on mobileMobile/responsive testing was missing.
All stories were marked DoneThe Definition of Done was probably weak.
Automated tests passedThe automated tests did not cover the right scenarios.

Teaching explanation

You can tell students:

“If all stories were marked Done and automated tests passed, but customers still experience major failures, then the team did not build quality deeply enough into the process. They may have tested something, but not the right things.”

What was missing?

Likely missing items:

Missing quality practiceExample
Strong Definition of DoneStory cannot be Done unless tested on desktop and mobile.
Better acceptance criteriaCheckout must work successfully for valid payment, failed payment, and mobile checkout.
End-to-end testingTest the complete user journey: login → order food → checkout → confirmation.
Mobile testingButtons and screens must work on common mobile screen sizes.
Regression testingExisting features like password reset must still work after new changes.
Exploratory testingHumans try unusual cases that automation may miss.

Best short classroom answer

No, quality was not truly built in. The team had a “Done” label and automated tests, but the tests and DoD were incomplete. Built-in quality means the team prevents defects through strong acceptance criteria, testing, review, mobile checks, and Definition of Done before the work is released.

A good discussion follow-up:

“What should be added to the Definition of Done so this problem does not happen again?”

From AI Tools as is

Jul 12

Kanban: flow over overload.

“Flow over overload” means:

In Kanban, the goal is to keep work moving smoothly through the system, instead of loading the team with too many tasks at the same time.

Your Kanban slide explains that WIP limits prevent overloading and help identify bottlenecks early.

Simple explanation

Bad approach: overloadBetter approach: flow
Start many tasks at onceStart fewer tasks
Many items stuck in progressItems move steadily to Done
People multitask too muchPeople focus and finish
Review/testing becomes blockedBottlenecks become visible
Team looks busy but delivers slowlyTeam delivers more predictably

Example

Suppose the team has 10 tasks.

Overload approach:

Everyone starts different tasks. Soon, 8 tasks are “In Progress,” 5 are waiting for Review, and almost nothing is Done.

Flow approach:

The team limits In Progress to 3 and Review to 2. They finish current tasks before starting new ones.

Teaching line

Kanban values smooth flow, not maximum busyness. A busy team is not always a productive team. The real goal is to move work to Done.

A good short phrase for students:

Stop starting. Start finishing.

REF: AI Tools as is