Versions Compared

Old Version 2

changes.mady.by.user Matthew Hall

Saved on

compared with

New Version 3

changes.mady.by.user Matthew Hall

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents
minLevel1
maxLevel6
outlinefalse
typeflat
printablefalse

Prioritization Criteria

Should we build it? How do we decide?

Prioritization happens at all levels. Individual, Team, Portfolio, and Value Stream. There are three areas for the Common Components Program where prioritization is particularly important.

  1. How do we decide which problem to solve next?

  2. One the problem is selected how to be choose which feature to use as the starting point for adding value?

  3. When should a team pause to get direction from senior management?

The following questions may help Product Owners to guide the effort efforts of their team.

These questions are not meant to be a checklist, rather they are tools to help you think critically about your roadmap and backlog and about the individual stories.

These question may also help team members to make certain technical decisions and determine how to handle technical debt.

Can our team independently decide to build it? Does this need to go up to Senior Management Team?

  • Is this a quarterly OKR-sized increment of work? 

  • Do we need to re-allocate resources to get this done?

  • Do we need to validate priority?

  • Do we need help/awareness from other teams?

    • Do we feel like there is too much WIP in our team right now and need some help on what to park?

    As well they will help you understand when it would be helpful to get strategic direction from senior management team.

    Choosing the Next Capability to Solve For

    Expand
    titleComponent Level Prioritization

    • Will a significant number of people care about this?

    • Is there someone who actually needs this?

    • Does this helps us solve something that is a high BC Government priority? (must know the list)

    • Does this help BC Gov teams other than yours to solve their problems?

    • Will this eliminate a duplication of effort that causing political concern?

    • Does this allow the automating of handoffs between consumers of your service?

    • Does this have tangible financial benefits? (lowers the amount of funding required to deliver,  eliminates a business process, enable repurposing resources to higher value work

    • Is there business agility in the team who will support it? 

    • Will this improve the trust, confidence, reliability, and stability in the support of the service?

    Selecting the Next Feature to Add for a Capability

    Expand
    titleFeature Level Prioritization

    • Will the feature make the product more useful to a larger audience of users?

    • Does the feature help to improve how the users trust the product?

    • Will more people choose to use it because of this feature?

    • Is the feature doing something that was previously hard work for someone to do in another way?

    • Is the planned work avoiding opinionated designs and instead allowing for configurable choice?

      • e.g. BCGov Theme can be selected, but if another province was using our product, could they easily select they own style library to use?

    • Does the contributed code increase the reputation of the team? (documentation, coding style, deployment and integration process, testing, accessibility, etc.)

    • Is there measurable value aligned to a user problem?

    Knowing When to Ask for Strategic Direction

    Expand
    titleStrategic Level Prioritization

    Can our team independently decide to build it? Does this need to go up to Senior Management Team?

    • Is this a quarterly OKR-sized increment of work? 

    • Do we need to re-allocate resources to get this done?

    • Do we need to validate priority?

    • Do we need help/awareness from other teams?

    • Do we feel like there is too much WIP in our team right now and need some help on what to park?