Thank you @fryorcraken for initiating this discussion. Lots to unpack and analyze here. These are some of my initial thoughts, I anticipate writing a follow up after further discussion and analysis.
Milestone Concept
The shift towards a value-based Milestone definition system and incorporating the Shape Up “Betting” system feels like a strategic move. Although this might include increased project management overhead, it should result in better estimation, delivery, and evaluation of the key Milestones.
The criteria proposed for Milestone definition feels appropriate, focusing on minimal scope will be crucial to eliminate the non-critical scoped work conundrum we have faced in the Gen 0 Milestone, where a number of issues and epics were de-prioritized leading up to the final delivery date.
A key challenge I’d like to focus on is how to best approach defining all the milestones for the year, especially with variables like node operator incentives still being researched.
Waku Work Cycle and Proposed Implementation
Referencing the image embedded here, there are a few unknowns highlighted within the process diagram I’d like to focus on. Particularly the Initial Research phase (research conducted before a milestone is defined), and the estimation requirements after POC work is completed, before reaching the sub-team epics and QA/Devrel epics.
Re: Betting, should we be placing two bets? One at the initial stage of working towards the POC and a second as we move beyond the POC/MVP phase? Would the bet be part of the review process post poc delivery?
I support organizing epics by subteam, this will provide more clarity on the content and ownership of each Epic. I agree the scattered kickoff dates might create a sense of distance with subteams as the work will be shipped at different times.
Preparing specific epics for QA and DevRel focuses will be vital for wider product adoption.
Research to MVP Case Study
In regard to splitting the example Milestone into two distinct Milestones, with all the descending Epics, I favor the the sense of progress and refined tracking views this approach will provide, albeit a great amount of issues required to create as a result.
I also need clarity on estimating work per epic, this likely should be done internally in teams for organizing work breakdowns, but how might we approach estimating by Epic if this is required in the definition of each Milestone?
Small Engineering Case Study
For the example given, I agree its best not to overengineer here. I would advocate to name this type of epic something like a Major-Epic rather than a Milestone-Epic to avoid confusion. Where a Major-Epic is a standalone peice of work, and a standard Epic is one under a normally defined Milestone.
Mix Research/Engineering Case Study
Would it still be useful to define the work under the epics to clearly outline the options available, to better inform the bets being placed?
Engineering
For the example given, one cc per Epic is not a negative outcome from my perspective, the Epic continues to serve its purpose of categorizing specific work as it relates to the Milestone.
Bug Fixes and DevEx/OperatorEx
I agree that an issue template for this category of issues with the accompanying docs is the right approach here.
Would it be appropriate to budget X% of the annual budget e.g. 10%, toward a Maintenance/Enhancement “catch-all” Milestone, that can serve to track and analyze the work in this category. This particular epic would probably be filled with “Major-Epic’s” as described above.
Looking forward to our collobarative effort in refining our Milestone approach, and feedback from leadership as we shape the final structure, definitions, and pm processes to ensure we’re aligned with broader objectives.