Estimate and plan
Two-week cycles give us a planning rhythm. Forecasts tell us early when a project is drifting; they are never a quota.
Our rhythm
We use Kanban with two-week cycles as a planning rhythm. Projects flow across cycles rather than being forced to fit inside one.
From rough size to target date
We may first size a project as two or three cycles. AI helps us map the project's critical path and simulate what happens as engineers join or leave it, so we can find the team size that finishes soonest without people waiting on each other.
Once the stories and tasks are broken down, the project lead sets an estimated target date. Product uses it to plan the release, training and documentation with the rest of the business.
If the timing doesn't meet the business need, product and engineering talk about reducing scope or whether more people could help.
Points and forecasts
Every task is estimated in Fibonacci points, which express relative size and complexity. A forecast turns the remaining points into a likely completion date:
- Our delivery history tells us how many hours a point usually takes across the team.
- We plan on a 40-hour week, with about 20% of it going to meetings and other overhead.
- The engineers assigned to the project, and their available time, give us a weekly capacity.
- Remaining points, converted to hours and divided by that capacity, give a projected finish date.
Because the forecast updates as work is completed or added, it shows early when scope has grown or a project is heading past its target date.
The conversion uses the whole team's history, so it's a planning input for the project. It's never an individual quota or a measure of an engineer's performance.
When dates move
Product and the lead stay aligned as scope and timing change. Engineering leadership compares the forecast with the lead's target. If the forecast is much later, we look at the assumptions and scope first, then talk with product. Product owns the business conversation about dates, expectations and scope.