Sprint Routines, Calendar Discipline, and What Carpal Tunnel Taught Me About Sustainable Output

Yesterday both my wrists flared up — carpal tunnel, both hands, the kind where typing feels like pressing keys through wet sand. I had a full sprint day planned: infrastructure PRs to review, a Terraform module to extend, Jira stories to groom. I did most of it, just not with my hands on the keyboard the way I normally would. It forced me to think about what actually needs hands and what doesn't — and that distinction turned out to be more useful than the original plan.

The sprint planning problem

I run my work week in loose sprints. Not formal two-week Scrum cycles — more like a rolling weekly planning session every Sunday night where I look at the Jira board, pull out what's realistic for the week, and block calendar time for each category of work. Deep implementation work (writing Terraform, code review, debugging) gets morning blocks before async load picks up. Support, architecture discussion, and documentation get afternoons. On-call and reactive work gets a float buffer I protect until Wednesday, at which point I release it back to project work if it hasn't been claimed.

This works well until something breaks the input assumption — a meeting-heavy week, an incident, or in this case, a physical limitation that made sustained keyboard use genuinely painful.

What you can do without full hand function

A lot, it turns out.

The automated code review workflow I've been building runs entirely through Claude Code CLI. Yesterday it did a full senior platform engineer review of a CAST AI installation PR — fetched the diff, ran five parallel analysis passes, scored findings against severity thresholds, posted an Adaptive Card to the Teams channel, and added inline GitHub comments to gaps the existing reviewers hadn't covered. End to end in seven minutes. I typed two commands to trigger it.

That's the point. When you've invested in good automation, a high-pain day doesn't mean a zero-output day. It means shifting which work you touch.

The work I moved to:
- Reviewing and triaging open PR comments (reading, not writing)
- Architecture conversations in Slack where I could think out responses and type short replies
- Grooming next sprint's story backlog in Jira — mostly clicking, light typing
- Writing specs and design notes in short bursts with long pauses
- Prioritizing which implementation tasks genuinely needed me vs. which could wait

The work I deferred:
- Any active coding that required long uninterrupted typing sessions
- Documentation rewrites
- Writing new infrastructure modules from scratch

The calendar side

The sprint planning layer is one thing. The calendar layer is where it falls apart for most people, myself included until recently.

I now block three categories explicitly on the calendar before the week starts:

Maker time: 90-minute blocks, no meetings, protected for implementation work. These are the first things I schedule. If they don't exist before the meeting invites start landing, they don't happen.

Reactive float: Two 30-minute unblocked windows per day. These absorb the Slack interrupts, urgent reviews, quick debugging sessions. If they fill, I don't schedule more — I triage into maker time only if it's truly blocking someone else.

Recovery: This is the one that took longest to treat seriously. At least one full non-screen hour mid-day. Not lunch at the desk. Not reading docs on my phone. Actual rest. On a wrists-are-bad day that window expands and I don't fight it.

The sprint stories themselves get tagged with an effort type: [keyboard-heavy], [review-only], [async-ok]. When capacity changes — because of health, because of an incident drain, because of anything — I can sort by effort type and immediately see what survives the constraint.

Audio input as a next step

Something I want to test during the next wrists-need-rest day: audio input to Claude Code CLI. The workflow already handles the heavy lifting of code reading, diff analysis, and PR interaction. If I can drive the prompting by voice — describe what I want reviewed, narrate a spec, think out loud into a design doc — the keyboard becomes optional for a much larger portion of the day than it is now.

I haven't tested it at full sprint capacity yet. The hand-to-voice translation isn't perfect for technical work — you lose precision on symbol-heavy content, command flags, exact variable names. But for the high-leverage tasks that are mostly about judgment and direction rather than precise input, it seems worth finding out.

The broader point is that sustainable output isn't about pushing through — it's about having enough redundancy in your toolchain and enough structure in your planning that a bad day (wrists, sick day, disrupted sleep) degrades gracefully rather than collapsing entirely. Yesterday was slower than a normal Tuesday. It wasn't a lost day.