Yuvraj’s approach
Identify the core issue with the current feature.: The unusable data for 30% of users is likely caused by one of the following: Hardware/OS Fragmentation: Background processes for continuous monitoring are being throttled by specific operating systems to save battery. Data Syncing Errors: High-frequency data packets are being lost or corrupted during the sync between the device and the app.
Evaluate the tradeoffs between fixing versus developing a fallback.: Risk Management: Prioritizing the fallback minimizes the chance of a total loss of functionality for the affected 30% of users. Stakeholder Confidence: Delivering a working feature, even if scaled back, maintains trust with stakeholders better than missing the deadline entirely. Resource Allocation: This approach allows the single developer and QA tester to work efficiently without the pressure of solving a potentially unsolvable bug under extreme time constraints. Decide which approach to take and justify the decision.: Decision: Develop the fallback feature (averaged heart rate over long intervals). Justification: With only one developer and one QA tester, attempting a high-risk fix on a complex, continuous monitoring feature is likely to fail within a two-week sprint. The fallback feature ensures that stakeholders see a functional, reliable product. It stabilizes the beta test and allows the team to gather meaningful, albeit less granular, health data rather than no data at all for a third of the users.
Outline immediate next steps if your approach is chosen.: Scope the Fallback: Define the exact intervals (e.g., 5-minute averages) and UI changes required for the fallback feature. Realign the Team: Shift the developer to building the fallback and the QA tester to writing test cases for the new data aggregation logic. Update Stakeholders: Inform stakeholders of the pivot, explaining that this guarantees a successful beta continuation while the continuous feature is re-architected post-beta.