Case study 02

LS module

The accessioning hub for Tiger LIS, taken over mid-build from a stalled freelancer engagement and put on a sustained release rhythm.

Problem

An external freelancer left the accessioning hub mid-build, with no owner and no release rhythm.

What I did

Took over the backlog, put full sprint discipline on it, and ran it to a sustained release cadence.

Result

136 items delivered in 9 months, at a 4-day median cycle time.

Role

Product owner

Timeframe

9 months, ongoing

Team

5 engineers

Stack

React, Spring Boot, Java

136

items delivered in 9 months

4 days

median cycle time

Context

siParadigm's accessioning workflow runs inside Tiger LIS, the lab's production Laboratory Information System. The LS module, a dedicated accessioning hub and a refactor of the legacy Tiger LS code, began under an external freelancer. When that engagement ended, the module was mid-build with no product owner. I took over end-to-end: requirements, backlog, sprint management, and release planning, with no handover period.

There were no written original requirements, so the backlog and the code itself were the only record of what had actually been decided. And Tiger LIS, the system this module integrates against, had changed drastically since the freelancer engagement began. Picking the work back up meant re-verifying which of the original requirements still held against the current state of Tiger LIS, not just resuming a build in progress.

The problem

The problem wasn't a missing feature, it was a missing owner. A module can sit mid-build indefinitely without anyone accountable for scope, priority, or a path to release. Every week without a release rhythm was a week the accessioning hub cost more to finish and proved less.

Why this and not something else

I could have kept working the freelancer's backlog as it stood and just added capacity. I didn't. I re-established ownership of scope and priorities from scratch and put full sprint discipline on the module from the first cycle, rather than trying to inherit years of undocumented work in place.

That discipline is the whole story here: 90% of all delivered work ran through sprints, the highest adoption of any product space in the company, and I set up a dedicated hotfix track separate from the regular release train so production-critical issues had a lane that didn't compete with planned work.

Decisions and tradeoffs

Inheriting a product mid-build without a handover forces you to rebuild context from artifacts, tickets, code, and users, instead of from a predecessor. I sized the module by working through what was already built rather than what had been planned, and rewrote the backlog against that reality: new stories, new acceptance criteria, and a sprint cadence.

The LS module's pre-accession form, showing separate patient information, client information, and case information sections above Save Case and New Case actions. — Pre-accession intake screen: patient, client, and case information captured in one form before a specimen is logged.

That intake form feeds worklists like the one below, where cases route by task status and assignee rather than sitting in one undifferentiated queue.

The LS module's Maxi worklist, listing cases by case number, patient name, client name, received date, task status, and assignee, each with a Start action. — Maxi worklist: cases in Ready status, queued by received date with a task assignee and a one-click start action.

Legacy Tiger LS wasn't lifted forward wholesale. Most of the new module was built using it as a reference for behavior, not as a codebase to refactor in place, and every API was written from scratch rather than adapted from the legacy layer.

Constraints

71% of resolved items were Critical or Blocker priority. This was high-stakes work from the start, not routine maintenance, on a team of 5 engineers with no ramp-up period. The release train reflects that: 3 releases and 2 hotfixes shipped in 9 months, with a fourth release already scoped and loaded, plus the dedicated hotfix track for anything that couldn't wait for the next planned release.

Outcome

Delivery sustained roughly 9 items a month, peaking at 36 in month three, despite a workload that was 71% Critical or Blocker. 51% of delivered work was feature stories against 43% bugs, the healthiest quality profile in the portfolio: the module was moving forward, not just being firefought.

Items delivered in 9 months, from a standing start

0 days

Median cycle time, creation to resolution

Delivered work that was feature stories, not bugs

The lab has moved to production use on the new module and has fully retired the legacy system it replaced. Turnaround time and user satisfaction both improved noticeably, and the entire accessioning team now works from it day to day.

What I'd do differently

Inheriting a product mid-build without handover forces you to rebuild context from artifacts, tickets, code, and users, instead of from a predecessor. That process discipline, sprints, a hotfix track, priority hygiene, was what converted an at-risk module into a predictable one. I'd still change one thing: I'd have rolled the module out to users iteratively, piece by piece, instead of building toward one larger release. Earlier user feedback would have caught more issues sooner, when they were cheaper to fix.

Open to technical product management roles.

ykrsandson@gmail.comLinkedIn