Feasibility Review Template proposal & feedback wanted!

Feasibility Review Template proposal & feedback wanted!

It has been raised a few times in maintainer calls and other calls that we don’t collectively as a software/product team (product, design, development and adopters) scope the cost in both time and effort terms as well as financially very well before undertaking a significant feature build.

This proposal is for a ‘tool’ (in the form of a collaborative spreadsheet) we can test and implement if we find it useful. This tool is a ‘feasibility review’ process within a spreadsheet template for the functions (product, design, development and adopters) to scope out complexity, time and costs associated with these build before we undertake the higher effort discovery tasks associated with Hypha feature builds.

Goal: To have a way to asynchronously cross communicate effort and cost of large scale feature builds in an open and clear way possibly leveraging a template that is open and replicable as well as being inclusive of adopters time and skills. There is an opportunity to have a video call synchronously to clarify or discuss any depth and detail that rises from the form.

Outcome: Feasibility reviews for each large scale feature build that can be open and iterative.

Please see a spreadsheet here: Feasibility Review Template - Google Sheets
(it’s open for editing and commenting but if you want to make direct feedback on the spreadsheet please use comments first. I do have a back up spreadsheet if anyone deletes anything by accident :slight_smile: )


So given the above info

Do you have any critical concerns about adopting the proposal?

Are there any clarifying questions you all might have?

Any quick reactions to the proposal above (e.g. good, feels weird, I don’t understand etc.)

1 Like

I really like the idea of this–I think, as @eriol said, it will improve efficiency and effectiveness of builds.

One note:

  • I’m a big fan of planning, though I sometimes over-plan, so for me, at least, it will be important to have clear procedures/guidelines laid out for using the template

Questions I have are below:

  1. Where does this fit in the development process?
    Right now I believe both new feature requests and bug fixes are posted in Github, or else float around in the aether :wind_face:, periodically bumping into different stakeholders :grinning:
    • Is the primary goal to use this for new feature builds?
    • Do we also use this for bug fixes?
    • What does the timeline look like in using this? Sub questions related to timeline below:
      • This form is used before any work is done, and before anything related to proposed new feature is posted in Github, right?
      • Do we want to set a max number of weeks/meetings we let this cook before we start taking action? (I can envision getting stuck in the planning)

  1. How does this interface with Github?
    Eventually some of the information (e.g. the “feature chunks”) will need to be turned into “issues” in Github that developers can assign and track?
    • So is the goal to get all parts of a new feature as broken down as possible in the spreadsheet, then transfer those tiny chunks into Github issues?
    • Do we want to link github issues directly in the sheet?
    • Who decides when it’s time to do this? (And who is responsible for doing it?)
    • Do we envision transferring any information from github back into this form (e.g., status updates)?

I’d really like to see a filled-in version of the form, if that’s possible–maybe we can either retroactively make one for the contracting feature, or prospectively make one for the reporting feature?

Looking forward to putting this into practice!