Versions Compared

Old Version 6

changes.mady.by.user Matthew Hall

Saved on

compared with

New Version Current

changes.mady.by.user Matthew Hall

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Page Tree
rootCommon Components Program

Home

Overview
startDepth

0

1

On this page:

Table of Contents
minLevel1
maxLevel6
outlinefalse
typelist
separatorbrackets
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 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. 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?

    Overview

    Prioritization is a fundamental aspect of our work at every level, from individual tasks to larger strategic decisions. As a Product Owner in the BC Government, you play a pivotal role in guiding these choices.

    The questions that follow serve as practical tools to assist you in making informed decisions for the Common Components Program. In the context of the Common Components Program, three key areas of prioritization require your attention.

    1. Knowing When to Seek Strategic Direction

    2. Selecting the Next Problem to Solve

    3. Choosing the Next Feature to Develop

    Knowing When to Seek Strategic Direction

    Usage

    Utilize these questions to determine when it's appropriate to seek strategic direction. They aid in understanding the scale of work, resource allocation, priority validation, and the need for collaboration with other teams.

    Criteria

    • Does our team have the autonomy to proceed, or does it require senior management input?

    • Is this a sizeable quarterly undertaking?

    • Do we need to reallocate resources to achieve this?

    • Should we validate the priority through collaboration with other teams?

    • Do we require assistance or input from other teams?

    • Do we perceive an excessive workload and need guidance on what to defer?

    Selecting the Next Problem to Solve

    Usage

    Consider these questions when comparing the value of discovery work. They help assess the problem's significance, alignment with government priorities, potential benefits, and impact on users and teams.

    This is for the size and effort level where a new team would be formed, or where an existing team would get more people added to it in order to conduct the discovery work into an area that extends past their current product vision.

    Criteria

    • Does this problem matter to a substantial number of people?

    • Is there a genuine need for this solution?

    • Does it align with high-priority initiatives in the BC Government?

    • Will it benefit other BC Government teams?

    • Does it eliminate unnecessary duplication?

    • Can it streamline interactions between service consumers?

    • Does it offer tangible financial advantages?

    • Is the supporting team agile enough to implement it effectively?

    • Will it enhance trust, confidence, reliability, and service stability?

    Choosing the Next Feature to Develop

    Usage

    These questions help measure the value of the outcomes of features. Considering its impact on users, trust-building, usability, flexibility, and overall value alignment.

    This is for the size and effort level where an existing team is resourced adequately to complete the work which align to their current product vision.

    Criteria

    • Will this feature expand the product's user base?

    • Does it enhance user trust in the product?

    • Will it attract more users due to its inclusion?

    • Does it simplify a previously complex task?

    • Does it avoid imposing specific design choices, allowing for flexibility?

    • For instance, can users easily customize their own style libraries?

    • Does it elevate the team's reputation through code quality and documentation?

    • Does it deliver measurable value tied to a user problem?

    Summary

    These questions are not a rigid checklist but rather tools to help you critically assess your roadmap, backlog, and individual stories. They also serve as guidance for technical decisions, handling technical debt, and identifying when senior management's strategic direction is beneficial.