You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current process to prioritise Engineering backlog items needs to be reviewed. The current sub-process How to prioritize backlog items doesn't adequately cover work coming from grants nor does it effectively reflect the use of the allocation buckets that we've been using in engineering.
This needs to be a conversation that includes feedback from Engineer, Partnership and Community Success and Product.
Measures of Success
We have an update source of truth, capture in the team compass that describes how work items are ranked (sequence and prioritized) for the engineering team.
In practice, I think for the last few months, the priority ordering has been:
New Hub requests
Anything else with a deadline
Partnerships support (although this is primarily managed via the #sync-partnerships-support-requests channel now)
Product Dev
Anything in Tech support (although this is also primarily managed via engineers reserving upto 30min of their time every day for support tasks, and me asking for this in #support-freshdesk)
Internal Engineering
Within these, the defacto prioritizer has been me - i've been ordering and sequencing tasks, based on my understanding of priorities from product and partnerships.
@yuvipanda, do you feel the percentages in the cross-referenced message are well represented in your above description? Alternatively, what would be the percentages for the list in your above prio-ordered list?
My impression goes toward most of the "board" capacity being deployed between Product Dev and Internal Engineering (I concur with you that 3 and 5 are now handled outside the board even when sometimes they might have associated github issues).
Within these, the defacto prioritizer has been me - i've been ordering and sequencing tasks, based on my understanding of priorities from product and partnerships.
I think this is problem (we are creating a new SPoF), and I would advocate to have Product and Partnership representation in the prioritization meeting so you are not the defacto prioritizer.
The current process to prioritise Engineering backlog items needs to be reviewed. The current sub-process How to prioritize backlog items doesn't adequately cover work coming from grants nor does it effectively reflect the use of the allocation buckets that we've been using in engineering.
This needs to be a conversation that includes feedback from Engineer, Partnership and Community Success and Product.
Measures of Success
The text was updated successfully, but these errors were encountered: