Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents
minLevel1
maxLevel7

Game Plan: Quality or speed?

Sprint Architecture

Length: 10 business days

With QA resources

Day 1, 2 and 3:

  • QA - Any backlog items that need to be tested from days 9 and 10 of last sprint.

  • QA - Ad-hoc testing of app (30min to 1 hr.).

  • QA - UAT prep - Word doc and spreadsheet creation.

  • Dev - Work on top priority backlog items

  • {PO -

    • {Option 1: Provide list of backlog items to users. They can test if they have time in ACC. If they do not have time, they do not have to test.}

    • {Option 2: PO hosts regular bi-weekly testing session with users to test backlog items completed last sprint. Users only attend if they can.}

Day 4, 5, 6, 7:

How to include: tech debt

Sprint Composition

30% - New development

30% - Testing Activities

10% - Bug Fixes

20% - Tech debt

10% - Release activities

Without QA resources

Day 1, 2 and 3:

...

Future consideration:

  • Security

  • Code coverage

Testing

Ad-hoc testing:

  • Dev, QA (Ewa), PO - 30min to 1hr per sprint

Basic level: - Dev’s only

  • Writing test cases

  • Reviewing each other test cases - manually

  • Executing each other test cases - manually

  • Still valuable - can start automating in the future

  • Careful not to add too many testing activities to the sprint for dev’s

Automated testing:

  • B Unit testing - more like unit testing for the UI - not full UI automated testing

Release Plan

1 month release schedule - Release Train

Total: 2 sprints

Sprint 1

Tech debt - some tech debt might need to be tested. But it is safe to do tech debt at the end of the sprint. At minimum, as sanity check might need to happen.

Dev:

60% - New development

10% - Bug Fixes

20% - Tech debt

10% - Release activities

QA:

70% - Backlog item testing

20% - User testing - day 10? Either PO or QA?

10% - UAT prep

Sprint 2

Sprint 3

Dev:

QA:

50% - ACC environment testing

50% - UAT testing (with users) - Test environment?

Sprint 4

Dev:

50% - Release activities

?? % - Critical bug fixes?

?? - ??

Dev - Release Architecture Needed

Manual to automated - Jugraj is working with Henry on this

One click deployment

Patch fixes - how do we implement?

Anything else?

Architecture: With QA resource - brainstorming only

Day 1, 2 and 3:

  • QA - Any backlog items that need to be tested from days 9 and 10 of last sprint.

  • QA - Ad-hoc testing of app (30min to 1 hr.).

  • QA - UAT prep - Word doc and spreadsheet creation.

  • Dev - Work on top priority backlog items

  • {PO -

    • {Option 1: Provide list of backlog items to users. They can test if they have time in ACC. If they do not have time, they do not have to test.}

    • {Option 2: PO hosts regular bi-weekly testing session with users to test backlog items completed last sprint. Users only attend if they can.}

Day 4, 5, 6, 7:

Testing - if QA resources - brainstorming only

If QA:

  • First three days, can catch up on testing

  • Writing test cases

  • Ad-hoc testing

  • Review test cases with one of dev team’s members

  • Executing test cases

  • Test all tickets within one sprint - if possible

Testing - brainstorming only

Discussion with Grace - April 4

Bugs addressed during the sprint. Leave some space for bug testing during the sprint

...

  • How to track modifications to backlog items. E.g. when testing, if something needs to be added, what should we do?

Discussion with Ashiq

PO and users:

  • test in ACC

  • They can test on the first day of the next sprint - will will give them a list of what we completed and they can test if they can, if not, that is ok - maybe 1 hr of testing for them

  • Dev - send a screenshot of new UI before the functionality is built to get feedback from PO via email. Do not need to send screenshots for things such as bugs, and FR translations. Only things we need feeback on.

  • PO walkover - two days before the end of sprint - 15-30 min to take a quick look if screenshots are not enough - flexible. PO may not need it every week.

    • Can show him work still in progress

  • Users can test in test environment if they wish after sprint review. We can give them a few bullet points of what we worked on. Either at end of review or first day of sprint.

...

How would we work with dev’s only to write test cases?

Discussion with Ashiq

QA free from manual testing

...

?? % - Critical bug fixes?

?? - ??

Dev - Release Architecture Needed

Manual to automated - Jugraj is working with Henry on this

...