Vega Product Owners

Backlog Grooming

Review/Groom/Prioritize backlog (frequency 3X a week minimum) - https://issues.folio.org/secure/RapidBoard.jspa?rapidView=68&view=planning.nodetail
Prioritize based on
- Chalmers showstopper. Is it detrimental to Chalmers' operations?
- Cap planning prioritization
- Bug Fixes (per Q1 2020 requirements - a sprint must be composed of 40% of bugs either team or core functional)
  - Core Functional Bug backlog - https://issues.folio.org/secure/RapidBoard.jspa?rapidView=79&view=planning.nodetail&quickFilter=656&quickFilter=354 (only take items that do not require the team to learn a brand new domain)
- Front-end | Stripes component and stripes core big test coverage.
- And if all else fails ask yourself - Is the story development ready?
If story does not require backend development then add the ui-only label to the story. Frontend developers will review this list https://issues.folio.org/secure/RapidBoard.jspa?rapidView=68&view=planning.nodetail# in addition to the entire backlog.
Backend Stories - Developers should create these stories once work is identified.
Release Stories - Developers should create these stories.

Key thing - opportunity for the team to ask questions and get unblocked on stories currently in the sprint - https://issues.folio.org/secure/RapidBoard.jspa?rapidView=68

PO Lead and Scrum master must work together to address blockers. If a story has been in 3 sprints then we have problem.

Vega is a unique team with multiple POs. PO Lead and Scrum-master must coordinate on making the call to POs for requirements. Team wants several days to review requirements prior to grooming.
PO lead prioritizes the list of stories for grooming.
PO lead or Scrum master post the stories for grooming on #vega slack channel.

In Review stories represent work that the is ready for the PO to test on snapshot. It is important that POs review stories at the end of the sprint to assess team velocity.
If the story has been in the In Review bucket for 3-4 business days then the team can reassign the story to be tested by manual testers BUT not some stories cannot be assigned to this group.
Also the PO lead may need to step in and verify the user story for doneness. OR gently nudge POs to do testing.
Another option is for the Scrum master to schedule a recurring review meeting to help move some stories to Done.

Retros

System Demos

When should a story be broken up to multiple stories? IMHO, if a story is estimated at 8 or higher then the PO and team should work on breaking up the story. Consider using the INVEST technique https://www.agilealliance.org/glossary/invest/