What HDD changed in SCRUM-279
Before HDD, the story was a workflow complaint. After one loop, the team had a sharper bet, a smaller proof slice, and a clearer decision gate.
The issue started as frustration about local board moves and provider status drift, but it did not yet name the real risk or the smallest slice worth proving.
HDD turned the complaint into one mapped-status-sync hypothesis, explicit acceptance criteria for Jira and GitHub, and a red-green-refactor proof path.
The story ended with verified mapped-sync behavior, a deployment gate, and a clear distinction between local test success and real-world dogfooding.
SCRUM-279 through the HDD skill
This is the start of the agent session, where the skill loads the story, identifies the real risk, and stops treating the issue like a generic implementation request. The example is styled like Codex, but the same loop also works in Claude and Copilot.
HDD makes the next decision concrete: what the team believes, what risk matters most, and what small slice can prove the point without expanding the story.
At this point the workflow stops being philosophy. The plan becomes red, green, refactor, with explicit provider-mapping rules and testable acceptance criteria.
HDD closes the loop with what passed, what was learned, and what still needs outside confirmation before the story is truly done.
Why engineering leaders care
HDD makes story readiness and decision quality visible before more delivery time lands on the wrong plan.
Handoffs carry intent
The next person sees what the team believed, what risk was being reduced, what changed, and what evidence is still needed.
Feedback is built in
Success metrics and demo steps make it harder to confuse shipping output with learning whether the outcome improved.
AI gets better context
AI coding agents like Codex, Claude, and Copilot can read the issue, plan, diagrams, and progress notes directly from the repo before writing code.
Start with one story, not a rollout
Use HDD on one active issue first. The goal is to prove that the team makes a better decision earlier, not to train the entire organization on a new framework all at once.
Start here
Pick one story that feels broad, unclear, or risky enough that the team could easily build the wrong thing without better context.
Watch for this
Measure whether the issue gets narrowed, clarified, or re-sequenced before more implementation time is spent.
Decide this next
After one loop, decide whether HDD made the story easier to start, easier to hand off, and easier to review with actual evidence.
Run the workflow on one real issue
Use imdone-cli to pull an issue into local markdown, run it through HDD, and review the result with the same artifacts you saw above.