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

Jul 12

Self-healing tests, Automation adapts when locators change.

Self-healing tests means:

Automated test scripts can adjust themselves when small changes happen in the application, especially in the UI.

What does “locator” mean?

In test automation, a locator is how the test finds an element on the screen.

Example:

Click the Login button

The automation tool needs to find the Login button using something like:

id = loginButton

or

xpath = /html/body/div/button[1]

or

text = Login

What problem happens?

Suppose the developer changes the button ID:

Old: id = loginButton
New: id = signInButton

A normal automated test may fail because it cannot find loginButton.

But the application may still be working. The test failed because the locator changed, not because the feature is broken.

Self-healing test example

A self-healing test may say:

“I cannot find loginButton, but I see another button with similar text, same location, and same function. It is probably the same Login button.”

So the automation adapts and continues the test.

Simple classroom explanation

Self-healing tests reduce false failures caused by small UI changes.

They are useful when:

  • button IDs change,
  • page layout changes slightly,
  • CSS class names change,
  • element location changes,
  • text changes slightly from “Login” to “Sign in.”

Important warning

Self-healing does not mean tests are always correct.

You can tell students:

“Self-healing tests are helpful, but humans still need to review important changes. If the test heals itself incorrectly, it may hide a real defect.”

Easy teaching line

Self-healing test automation means the test can still find the right UI element even when the technical locator changes.

REF: AI Tools as is

Jul 12

Debrief?? One group shares one strong DoD item.??

Yes. Debrief means the short discussion after the activity.

After students finish the RCA/Fishbone/Five Whys activity, you ask them to share what they found.

Meaning of this line

One group shares one strong DoD item

It means:

Each group should give one good Definition of Done checklist item that could prevent this problem from happening again.

Example classroom instruction

You can say:

“Now we will debrief. Each group, please share one strong Definition of Done item that would have prevented the checkout crash or mobile button issue.”

Strong DoD examples students may give

Weak DoD itemStrong DoD item
“Testing completed”“Checkout must be tested successfully on desktop and mobile before the story is marked Done.”
“Code works”“All acceptance criteria must pass, including happy path and error cases.”
“Reviewed by team”“Code review and QA review must be completed before moving to Done.”
“UI completed”“UI buttons must be tested on common mobile screen sizes.”

Best example answer

A strong DoD item would be:

A user story cannot be marked Done unless it passes functional testing on both desktop and mobile, all acceptance criteria are verified, and no critical defects remain open.

How to explain debrief to students

“Debrief means we stop the group work and learn from each other. We are not only checking the answer. We are asking: what did your group discover, and how would you improve the process next time?”

REF: AI Tools as is

Jul 12

how fishbone helps to find root cause

Fishbone helps find the root cause by organizing possible causes into categories, so the team does not jump to one quick answer or blame one person too early. It is a visual RCA tool used to identify possible causes of a problem.

Simple explanation for students

“Fishbone does not automatically give the root cause. It helps the team brainstorm, organize, compare, and narrow down possible causes until the most likely root cause becomes visible.”

How it works

Problem:

Checkout crashes 40% of the time

Fishbone categories:

People --------\
Process --------\
Tools -----------> PROBLEM: Checkout crashes 40% of the time
Testing --------/
DoD ------------/
Environment ---/

Then the team asks:

CategoryPossible causes
PeopleDeveloper rushed, reviewer missed issue
ProcessNo mobile testing step, weak release checklist
ToolsAutomated tests did not catch checkout crash
TestingOnly happy-path testing, no edge-case testing
Definition of DoneStory marked Done without mobile validation
EnvironmentTest environment different from production

How it leads to the root cause

After listing possible causes, the team looks for the causes that are most likely, most repeated, or supported by evidence.

For example, the team may discover:

The checkout failed mostly on mobile devices, but mobile testing was not part of the Definition of Done.

So the root cause may be:

The team’s Definition of Done did not require mobile checkout testing before release.

Teaching line

Fishbone helps us move from “What went wrong?” to “What could have caused it?” and then to “Which cause should we fix so the problem does not happen again?”

Ref: AI Tools as is

Jul 12

Fishbone

Yes. Fishbone Analysis should usually be shown as a diagram, because it is a visual Root Cause Analysis tool. It is also called an Ishikawa Diagram or Cause-and-Effect Diagram. Your slide defines it as a visual tool for identifying possible causes of a specific problem.

Simple Fishbone Diagram Example

Problem:

Checkout crashes 40% of the time

                           People
               Not enough QA training
                    No reviewer assigned
                              \
                               \
Process ------------------------\ 
No mobile test checklist          \
No release approval step           \
                                  \
Tools ----------------------------->  PROBLEM:
Test automation missed mobile      Checkout crashes
No crash-monitoring tool           40% of the time
                                  /
Testing --------------------------/
Only happy-path tests
No stress / edge-case tests
                                 /
Definition of Done -------------/
AC checked, but mobile testing missing
Security/performance not checked
                                 /
Environment -------------------/
Different mobile browsers
Production data different from test data

How to explain it to students

“The fish head is the problem. The bones are major cause categories. Under each bone, we write possible causes. We are not choosing the final answer immediately. First, we brainstorm possible causes. Then we analyze which causes are most likely to be the real root cause.”

Cleaner classroom version

People --------\
Process --------\
Tools -----------> PROBLEM: Checkout crashes 40% of the time
Testing --------/
DoD ------------/
Environment ---/

Then students add details under each category.

Example causes

CategoryPossible causes
PeopleDeveloper rushed, reviewer missed issue, QA not involved early
ProcessNo mobile testing step, weak release checklist
ToolsAutomated tests did not cover checkout crash
TestingOnly normal cases tested, no edge cases
Definition of DoneStory marked Done without mobile validation
EnvironmentProduction data/browser/device different from test environment

Teaching line

Fishbone helps the team avoid blaming one person too quickly. It shows that quality problems usually come from multiple causes: people, process, tools, testing, and environment.

Ref: AI Tools