Process Development
Sprint planning on Basecamp. Daily Basecamp todos. Friday written status report on staging URL. Sprint review and retro at the end. Predictable cadence, predictable shipping, every decision in writing.
Most project disasters happen because the customer cannot tell what the team is doing until the deadline. The cadence below is designed to make that impossible. Basecamp todos updated daily, Friday status reports in writing, sprint reviews every two weeks. You always know what is happening, and you have the written record to prove it.
The five steps
Five activities that repeat every sprint. Same shape, same touchpoints, same artifacts. Predictability is the point.
01
First day of the sprint. Engineering lead and customer product owner agree the sprint backlog inside Basecamp. Acceptance criteria written for every todo. Estimated work fits the team capacity for the next two weeks. Everything is documented before any code gets written.
Sprint goal is one sentence everyone agrees on, written in Basecamp.
02
Every working day, the assigned engineer updates their Basecamp todos with progress notes. What shipped, what is in progress, what is blocked. Customer team reads on their schedule, comments inline. No standup meetings, no status emails.
Full daily history of decisions, written, searchable, never lost.
03
Every Friday, a written status report posted to Basecamp message board. Hours consumed and remaining, what shipped, what is in progress, what is at risk. Optional 30-minute demo call for stakeholders who want a live walkthrough on staging.
Customer always knows where the project is, in writing.
04
Last day of the sprint. Sprint review walks through every item against acceptance criteria. Retro covers what worked, what did not, what changes for the next sprint. Customer team participates. Notes posted to Basecamp.
Process improves sprint by sprint, not at quarter end.
05
Mid-sprint, engineering lead and product owner refine the backlog for the next sprint. New requirements added. Stale items removed. Estimates updated based on what we learned this sprint.
Next sprint is ready to plan on day one.
Most communication happens on Basecamp, in writing, that anyone can read on their own schedule. Sync meetings are reserved for sprint planning and the optional Friday demo call. We do not run daily standups for client teams. We do not require customer engineers to be on call.
Velocity sprint over sprint. Time from "in progress" to "in review" to "shipped" per task. Time from PR open to PR merge. Bug discovery rate sprint over sprint. Hours consumed against the upfront block (for pay-as-you-go) or against the sprint scope (for fixed-price). Internal dashboards track these and we report them in the Friday status report and sprint review.
We do not track hours per task at the engineer level for surveillance. Hours are tracked at the engagement level for billing transparency, not at the engineer level for micromanagement. Effort is tracked at the sprint level for capacity planning.
Read access to the GitHub repository. Basecamp project access with full todo history, message board, file uploads, schedule. PR review comments visible. Friday status report archive. Sprint demo recording within an hour of the live demo. Sprint review and retro notes posted to Basecamp at sprint end. Engineering is not a black box.
Common questions
One week is too short to ship anything substantial. Three weeks loses the rhythm of regular demos. Two weeks fits planning, building, demoing, reviewing, retro-ing into a cadence the customer team can rely on.
Basecamp keeps the entire project history in one place: todos, message board, schedule, files, decisions. Nothing goes missing in Slack DMs. Nothing gets buried under Jira workflow customizations. Customers can audit the full project history anytime.
Mid-sprint scope changes are absorbed into the next sprint, not the current one. Current sprint stays focused on its committed goal. If a true emergency requires breaking the sprint, we do, but we surface the cost transparently in the Friday status report.
No. They are async. Read them when you are ready, comment async. The Friday written status is the only thing we strongly recommend reading every week.
Async-first by design. Basecamp updates work across timezones because they are written. Demos are scheduled for overlap windows. Sprint planning is one to two hours of synchronous time we book to fit your timezone preference.
Four business hours during business days for any Basecamp question or comment. Faster on retainer engagements. Outside business hours, we respond next morning unless you have an enterprise SLA.
Ready to start the sprint cadence?
The first sprint begins the week after discovery and contract sign.
After 16 years of buying WordPress themes and plugins, I know exactly what bad support looks like and Wbcom Designs is the polar opposite. My setup was a nightmare: multiple tools, deep integrations, custom configurations that required…