Release Calendar was a content-release scheduling tool for one of Disney's product teams. Drag-and-drop date grid, dynamic re-anchoring when dependencies shifted, multi-view layouts (week / month / quarter). MVP from kickoff to internal-tool-in-use in two sprints.
The brief
The team was tracking releases in a spreadsheet that everyone hated. Dates moved constantly; dependencies between releases shifted; the spreadsheet's columns didn't match anyone's mental model. They wanted a calendar UI that handled drag-to-reschedule, rolled changes through dependent dates automatically, and let different teams see the same data through different lenses (PM wants a quarter view; producer wants a week view; exec wants a milestone view).
Two sprints. No carve-outs.
How the work shipped
Sprint one: clickable prototype + the data model. Reschedule logic was the hardest part — moving a release backward should ripple to dependents, but only if those dependents were anchor-locked. The wrong default would be worse than the spreadsheet. We pinned the rules early so engineering had a reliable contract by sprint two.
Sprint two: build the React surface. Drag handles, the dependency engine, the three view modes. Tests on the date math because that was the layer most likely to silently break. Internal release at the end of week four.
Why this is the case study
Most product work at this scale takes longer because the team can't agree on the rules. The forcing function on Release Calendar was the two-sprint constraint — there wasn't time to litigate every decision, so we made trade-offs visible early and kept moving. The MVP shipped because it was scoped to be shippable, not because the team worked harder.
That same constraint shape — short cycle, forced trade-offs, ship the floor — is what produces working AI systems instead of working AI demos. The design discipline transfers.
Why this matters for AI systems
AI tooling work tends to over-scope. Teams want the eval harness, the trace viewer, the labeling pipeline, the safety review queue, all in v1. Then six months pass and nothing has shipped, because the integration surface area was the actual blocker.
The Release Calendar move — two sprints, scoped to the floor, ship the rules-engine first because it's the thing other systems depend on — is exactly how to get an AI ops surface into production. Pick the part the rest of the system needs to depend on. Ship that. Layer the rest later, on the contract you established in sprint one.