Welcome back to the dev log. Last week, Collin and I officially pivoted MedReach AI into a "Data Intelligence First" platform, locking in our enterprise architecture and securing our multi-tenant data models. This week, the planning phase ended. Sprint 1 officially kicked off, marking our transition into active software engineering.
However, as we moved to pull our Phase A (Data Management MVP) tasks from the backlog, we immediately encountered a classic software development trap.
The Problem: The "8-Point Ticket" Trap
As the Scrum Master for this project, my goal is to protect our team’s velocity and prevent burnout. While planning Sprint 1, I noticed several of our backend architectural tickets—such as integrating Microsoft Presidio for PII scrubbing and building our async CMS NPI Registry validation pipeline—were estimated at 8 Story Points.
In Agile development, especially for a two-man capstone team balancing outside lives and careers, an 8-point ticket is functionally a monolith. It represents too much ambiguity. If a single ticket takes 20+ hours to complete, it risks sitting in the "In Progress" column for the entire sprint. If I hit a bug on day two, my velocity flatlines, and worse, I become a bottleneck for my frontend partner who is waiting on that API contract.
Caption: Breaking down our Phase A backlog into highly granular, sprint-ready deliverables.
The Solution: The 4-Point Hard Cap
To solve this, I enforced a strict Agile capacity rule for our board: No single task can exceed 4 Story Points.
We mapped our estimation scale directly to our weekly capacity, where 1 point equals roughly 4 to 5 hours of engineering work. By capping tickets at 4 points, we ensure that the absolute maximum size of any task represents one week of part-time capacity (approx. 20 hours).
I spent the first part of this week slicing our backend monoliths into testable, bite-sized components. For example, instead of one massive ticket for "NPI Validation," we now have separate 2- and 3-point tickets for the base REST connection, the async batching queue, and the local caching layer. This granularity guarantees that even if we hit a roadblock, we can still merge smaller victories and keep the burndown chart moving.
Execution: Architecting the Phase A Backend
With our sprint scope cleanly defined, I swapped my Scrum Master hat for my Backend Architect hat. My primary technical focus this week was our most critical MVP blocker: Security and Ingestion.
JWT Middleware & Multi-Tenant Isolation: Before parsing a single CSV, we had to ensure our data boundaries were airtight. I mapped out and configured the Firebase Authentication middleware to intercept API requests and validate custom Role-Based Access Control (RBAC) claims. This ensures that an Editor in Company A can never access, query, or mutate data belonging to Company B at the database level.
Chunked Ingestion Pipeline: I also began scaffolding the pandas chunked CSV reader. Because enterprise healthcare datasets can be massive, this async ingestion engine is designed to parse large files without maxing out our server's memory, passing the data smoothly to our heuristic column detection logic.
Caption: The MedReach AI Multi-Tenant Isolation & Role-Based Access Control architecture, defining strict database-level boundaries and the permission matrix for our Phase A MVP.
What’s Next?
By slicing our tasks down and securing the gateway, we have created a safe, isolated sandbox to begin heavy data manipulation. Next week, I will be deep-diving into the Microsoft Presidio integration to automate our PII/PHI redaction engine.
Until next time, keep your sprints short and your endpoints secure!
Top comments (0)