HFI Calculator: Configure dynamic prep date range windows

[conbrad]

As a HFI User (plans/co) I want to configure start days and end days to automatically create prep periods So That I don't have to manually set prep period ranges

Additional Context

• Feedback from DK and SI in NWFC
• Screen shot of meeting occurrence creation in Outlook for inspo:

Acceptance Criteria

• [ ] Given I submit a date range configuration, When the current prep period finishes, Then the next date range creates a prep period based on the date range

Definition of Done

• Ready to Demo in Sprint Review
• Does what I have made have appropriate test coverage?
• Documentation and/or scientific documentation exists and can be found
• Peer Reviewed by 2 people on the team
• Manual testing of all PRs in Dev and Prod
• Merged

[tessmgood]

This is the better solution over 1860. Sybrand and I chatted about it recently, sorry for not sharing that.

I started mapping out all the considerations in Figma but got pulled away:

• base automation logic (Mon/Thurs)
• exceptions (long weekends/stats (also automatable?), shoulder season that is 7 day prep periods (harder to automate, varies by FC))
• the Operations CoP Lead wants to see us go toward daily prep checks, vs. 2x a week (business context, policy) - future goal to be aware of
• need clarity in the interface: current prep period, navigation to previous preps to look at trends and actuals
• CRUD x interface — how do we handle the exceptions above or unique circumstances
• this is top of mind - what am I missing?

This is me looking at the big picture, I know this can be broken up into pieces but want to consider it all up front so the puzzle all fits together in the end.

[conbrad]

this is top of mind - what am I missing?

I think you've captured all the high level features thoroughly. What might make sense is to do is to figure out what atomic features from this list can be worked on independently, so that we can break down the technical implications of each feature.

For example, base automation logic and any exceptions are dependent, CRUD x interface it's own thing. It may not make sense to ship these independently, but breaking the problem down independently would be useful.