Forecasting and dates, answered in full.

Start counting this week and forecast anyway. Four weekly throughput samples give a crude range that beats an invented date, and you widen the gap between p50 and p85 to reflect how thin the data is. The numbers have to come from this team's own flow, so do not borrow another team's velocity or an industry benchmark. Until the samples build up, lean on gate dates as the primary signal, because they are observable from day one and need no history to mean something.

Give them the p85 as their one date. That is what the range is for. You plan the team against the p50, you commit externally to the p85, and you keep the p50 inside the team because outside it the earlier number is heard as the date. Say the p85 is a date you expect to beat five times in six, based on the last three quarters of this team's throughput and an item count you publish alongside it. That answer survives week nine, which a confident single date does not. Tenhaw gives its own clients p85 dates for exactly this reason, and publishes the method that produces them.

The date stops being the variable and scope becomes the variable, so run the simulation backwards. Ask how many items this team finishes by the fixed date at p85, compare that with the item count in the epic, and the difference is scope you cut now rather than in the final fortnight. Take it out explicitly, restate the epic's planned currency value at the reduced scope, and have that accepted by name. Tenhaw works to hard windows of its own, and a proof of concept for a London specialty insurance business took PDFs through to business intelligence on Azure inside two weeks, ground it had circled for roughly a year. A fixed date with unfixed scope is not a commitment, it is a countdown.

Any movement that puts the p85 past the committed date on the table, however small, and any gate date that moves at all. Everything else stays inside the team. The accountable person then hears from you rarely, and when they do it always means a decision is needed, which is what keeps escalation cheap and credible. Escalating every wobble in the p50 trains people to ignore you, which is how the week-eleven surprise reaches teams that were technically reporting all along.

Because most teams track percentage complete, which is self-reported, converges on ninety per cent and sits there until the final fortnight makes it unignorable. Ship dates slip because approval gates slip first, weeks ahead of the deadline, so the slip itself was there much earlier and in plain view. Tenhaw installs that early warning on the client programmes it runs. Show days-to-gate on every epic, review it weekly, and treat any gate date that moves as a ship date that has already moved at least as far. Add a fortnightly re-forecast from your own throughput and no slip needs to reach the accountable person later than the fortnight in which the numbers first showed it.

No. You cannot make a late epic early by pushing, which is why delivering on time is a detection problem rather than an effort problem. The teams that land their quarters are the ones that see the slip in week four instead of week eleven, while cutting scope, moving an epic or reallocating people are still real choices. That takes four habits: commit to dates derived from your own throughput, watch approval gates as the early warning, re-forecast every fortnight, and turn every slip into a priced decision with a named owner. Tenhaw runs those four habits with teams of two or three senior people, James Rooney on every engagement, rather than a surge at the end.

Four, and the job is to arrive with all of them costed rather than with a status update. Tenhaw's delivery leads cost the same four for clients before a slip reaches a sponsor. Cut scope inside the epic, naming which stories or user journeys come out and what the planned value drops to. Move the epic to next quarter and move its currency share with it, so the outcome gap shows in the plan. Pull people off a named lower-value epic and state what that epic loses. Or accept the later date and say what it costs in months of value monitoring. One named person picks, the decision and its date go in the RAID log, and the roadmap is edited to match the choice.

From throughput, every time. Counting available developer days and dividing assumes nobody is interrupted, blocked, ill or on holiday, and historical throughput already has all of that baked in. Export the last two or three quarters of finished work from your tracker and count completed items per team per week, stories for an AI-augmented team and outcome tickets for an AI-native one. Keep the weekly samples raw, bad weeks, holidays and incident weeks included, because those recur. Aim for at least twelve samples, record a start and a done date for every item so you get cycle time as well, then simulate against the remaining item count and read the distribution rather than averaging it.

Moving the date can be the right decision; moving it quietly never is. Re-baselining the commitment to match the current forecast makes every quarter look successful and destroys the calibration data the next forecast needs, so if the date moves, record that it moved, when, and why. The honest route is to raise the slip the same day the fortnightly re-forecast shows the p85 crossing the committed date, put the choice to the accountable person with the value at risk attached, and edit the roadmap to match whatever they decide. At quarter close, count how many committed epics actually landed, so the next plan inherits your record rather than your optimism.

No. An outcome ticket counts as done only when its test requirements pass and its key user journeys are demonstrated working, never when the model reports it has finished. Count the model's word as done and your throughput inflates, the forecast built on it tightens, and the slip you should have seen in week four surfaces in value monitoring instead. Tenhaw holds that line on its own client builds, against an open-source standard of 72 rules enforced by an agent. Forecasting in outcome tickets also needs patience. An AI-native team may finish two or three a week rather than nine stories, so the samples are fewer and fatter and the gap between p50 and p85 is wider for the same confidence.

Both, at different points, and the split is what makes the date mean anything. Tenhaw staffs the delivery lead's half of that split on client programmes it runs. Every committed date on the quarter's table carries the name of the person who accepted it, and that person owns the decision when the date comes under threat. The delivery lead owns detection: tracking days-to-gate, re-forecasting every fortnight, and putting the slip in front of the accountable person the day the numbers show it, with the options costed and the value at risk attached. What a delivery lead must not do is choose quietly on the sponsor's behalf, because a date moved without a named decision destroys the record the next forecast is built on.

Two. A third converts into cycle time rather than output, so cap epics in flight per team and stagger start dates instead. What makes the cap real is a portfolio view: lay every epic in the quarter on one timeline, mark the named people or teams each one needs, and find the weeks where two epics want the same person, because capacity is shared even when boards are not. Move start dates until every epic clears its p85 inside the quarter, then redo the arithmetic. If the moved epics no longer cover their outcomes' currency targets, that gap gets a named owner before the quarter opens. One safe epic and three sitting at p50 is not a schedule.

It means the whole commitment table landed, not that one epic landed. Before the quarter starts, put every epic on one table and give each row four things: the date it must clear Ready for Dev, the date it must ship and be in value monitoring, its planned share of its outcome's currency target, and the name of the person who accepted that date. The standing Tech Debt and Bug Budget epics sit on it too, because they consume the same capacity. That table is the commitment, it lives where the business can read it without asking, and on time is a property of all of it rather than of the epic being asked about loudest.

Because on time was always a property of the whole roadmap rather than of the epic with the most senior sponsor. The rescue takes people from somewhere, three other epics drift unwatched, and the arithmetic that mattered was never redone. If people move, name the lower-value epic they come off, state what it loses and re-forecast it, because its p85 moves too. Keep days-to-gate visible on every epic in the quarter rather than on the escalated one alone, and let the fortnightly re-forecast cover all of them. Then reallocation is a priced trade with a named owner, and the epics nobody rescued stop being a surprise in week eleven.

Measure the ratio and carry it into the next plan instead of promising the full number again. Tenhaw reports a month that delivers no measurable value as a failed month for the same reason. At quarter close, once outcome validation has caught up, compute validated currency value over planned currency value. Plan four million, validate two point eight, and every forecast you publish afterwards carries seventy per cent. Compute the landed hit rate alongside it, committed epics that shipped over committed epics. Do both before you open the next roadmap, which otherwise inherits last quarter's overrun. That ratio puts the shortfall on the table in week one, where a sponsor can add an epic or accept a lower target, rather than in October.

Anything not on the quarter's table is not committed, and you say so the first day the assumption surfaces. That is blunt, and it is far cheaper than a business planning around a date nobody ever accepted. Then treat the request as what it is, a change to the commitment rather than a favour. Putting it on the table means a named person accepts its dates, and it means something else moves, so arrive with the options costed: cut scope inside a named epic, move one to next quarter, or accept a later date and say what that costs in months of value monitoring. One person decides, the decision goes in the RAID log, and the roadmap is edited to match.

Take an invented retailer and invented numbers. A 600k guest checkout epic holds 46 items, inflated to 55 for historical scope growth, so the p50 lands on 5 September and the p85 on 12 September, and 12 September becomes the commitment. In week four the daily lookahead flags days-to-gate going negative, because engineering approval is stuck behind payment sandbox access, and the gate moves two weeks. At the next refinement the count is 58 and the p85 is 3 October. The sponsor cuts the saved-card journey, dropping planned value to 380k, and moves one engineer off a 500k epic, which slips nine days. Found in week eleven, the only surviving option is 3 October.

It is, and it is worth reading weekly rather than at the end. The Bug Budget epic sits on the same commitment table as everything else, so time spent over its budget is time taken from committed work. The daily lookahead compares its burn rate with the same week last quarter, which beats arguing about whether things feel noisier than usual, and a burn running ahead of that comparison is capacity quietly leaving the plan. It will surface soon enough in the fortnightly re-forecast as a p85 drifting past a committed date. Raise it the same day, exactly as you would a gate that has moved, and name the epic it is costing.