Tab Merge: Cost Estimates of Options

###### tags: `Tab Merge` `Nov` `2019` # Tab Merge: Cost Estimates of Options ::: info 1 dev sprint = 1 dev resource working full time for 1 sprint **Estimation Summaries:** - Detail Tab Enhancement & Configurable PDF Features ---> 18 to 23 dev sprints - Configurable PDF Enhancement ---> 7 to 11.5 dev sprints - Configurable PDF Enhancement & Detail Tab Features ---> 18 to 28 dev sprints - Bare minimum for performant Configurable PDF ---> 6 to 10 dev sprints ::: ### 1. How long would it take to complete what we had originally planned? The [original estimate was 13-16 dev sprints](https://github.com/procore/adr/blob/master/procore-pay/020_prioritization_of_tab_merge.md). #### New Considerations: - Support Unit Qty Rounding Bug Fix [Part 1](https://procoretech.atlassian.net/browse/CF-8769) and [Part 2](https://procoretech.atlassian.net/browse/CF-8921) (0.5 dev sprints) - Addressing bugs from `core-react` and `react` library upgrades (0.5-1 dev sprints) - Factor in QA + Code review (added 30% to estimates) #### New Estimate: - Best Case: 18.5 dev sprints - Nominal Case: 21 dev sprints - Worst Case: 23 dev sprints #### Notes - We would not see performance benefits for the configurable PDF until the entire tab merge is complete. --- ### 2. How long would it take to complete the configurable PDF enhancement? We had originally planned to create an enhanced detail tab and add configurable PDF features. If we enhance the configurable PDF first, we have to add scopes of work for features that would have otherwise already been built with an enhanced detail tab. These features, however, won't exist yet because of the new approach. #### New Considerations: - Replace legacy table with Pakaukau (0.5-1 dev sprints) - Support g703 table headers (1-2 dev sprints) - Support Materials, Work, and Materials + Work Retainage Columns (0.5-1 dev sprints) - Support Unit/Qty and Amount based Columns (0.5-1 dev sprints) #### New Estimate: - Best Case: 7 dev sprints - Nominal Case: 9.5 dev sprints - Worst Case: 11.5 dev sprints --- ### 3. How much longer would it take to complete the tab merge if we add detail tab features to an enhanced configurable pdf? #### New Considerations: - Add and Remove Change Orders (1-2 dev sprints) - Inline Edit Cells (1-2 dev sprints) - Bulk Set and Release Retainage (1-1.5 dev sprints) - Prefill payment application with sub invoices (1 dev sprints) - Custom Ecrion PDFs (0.5 dev sprints) - G703 Math (1-1.5 dev sprints) - Footer Math (0.5 dev sprints) - Work Completed Calculator (1-1.5 dev sprints) - Would not typically be done - Overbilling (0.5-1 dev sprint) - Currency Input (0.5-1 dev sprints) - Retainage Validation (0.5-1 dev sprints) - COBLI Grouping (1-1.5 dev sprints) - Multi-tiered Change Order (1 dev sprint) - Requires BE change to API contract - Permissions (0.5-1 dev sprints) - Item Number Increment (0.5 dev sprints) #### New Estimate: - Best Case: 18.5 dev sprints - Nominal Case: 24.5 sprints - Worst Case: 28 dev sprints --- ### 4. What if we just replace the configurable PDF table with Pakaukau? How long would it take? #### New Considerations: We would still need to entirely rebuild: - Persistence of collapsed and expanded group rows (0.5-1 dev sprints) - Custom bill code assignment (1 dev sprint) - Configrable PDF export (0.5-1 dev sprints) - Unit/qty and amount based headers (0.5-1 dev sprints) We would need to somewhat refactor: - User controlled table grouping (0.5 dev sprints) - Always editable description of work (0.25 dev sprints) - Permissions (0.5 dev sprints) - G703 table headers (0.5 - 1 dev sprints) - Materials, Work, and Materials + Work Retainage Columns (0.5 dev sprints) - Unit/Qty and Amount based contracts (0.5 dev sprints) #### New Estimate: - Best Case: 6 dev sprints - Nominal Case: 8 dev sprints - Worst Case: 10 dev sprints --- ### Notes #### Confidence Level: 60% - 70% confidence - I wrote most of the code for configrable PDF. - I however, have not worked with the code in close to a year. - I also did not create a spike or investigate configurable PDF enhancement extensively #### Assumptions: - We continue with refactoring patterns as we had planned months ago, even if it's not current best practice (state management, handling async requests, etc.) - Each scope of work includes specs, any necessary refactoring, Code Review, and QA - The UX paradigms outlined in mocks are exactly what we build, although they might change because they are outdated - https://procore.invisionapp.com/share/4TONSH9H5FD#/screens/264233523 - https://procore.invisionapp.com/share/JVOUBS0Y2SP#/screens/328387356 #### Why are best case estimates for the original approach and the new approach the same? - When executing the Detail Enhancement, we had planned to refactor features to be open to addition of configurable PDF features. - When executing the Configurable PDF Enhancement, the Detail features #### Action Items - [x] Write notes about question --> "Why are best case estimates for detail + config PDF the same as config PDF + detail?"" (JY) - [x] What would this look like with multiple developers? (JY) - [x] Project summary (LM, JY, KF) - Problem statements - Options - Proposed solution