At PI planning the platform team was honest about it. Roughly a quarter of every sprint goes to keeping the lights on: patches, the on-call rotation, support tickets that come up from customer success. They said so out loud, the release scope was sized around the other three quarters, and the team voted four fingers for 4 December.

In week three a vendor announced end of support for the database driver the product runs on. Security wanted it replaced before year end. Two engineers moved onto the upgrade and the patch queue behind it. Nobody added a single issue to the release. The roadmap still showed 4 December in green.

KTLO meaning: keep the lights on

KTLO stands for keep the lights on. It is the baseline work that keeps existing systems running without adding new features: bug fixes, security patches, dependency and infrastructure upgrades, incident response and on-call, and customer support escalations. Some teams call the same bucket BAU (business as usual); others use BAU for routine operations more broadly. Industry write-ups commonly put KTLO at a third to a half of engineering capacity in mature organisations, and much less in young products.

KTLO work is not waste. Skip it and systems fail, vulnerabilities pile up and customers leave. When a team names its KTLO share at planning, that is expert engineering judgment about how much of its week the existing product will claim. It is part of the evidence behind the confidence vote, and it belongs there.

The share is set once. KTLO work is not.

The trouble is the number. “About 25% KTLO” is agreed on planning day and then nobody reads it again. KTLO work does not hold still after the vote. Four things change it, and the release plan shows none of them.

Patch waves. A critical vulnerability lands in a library the product depends on, and every service needs an upgrade this sprint.

End-of-life deadlines. A runtime, driver or cloud service reaches end of support. The work was always coming; the date it lands is set by someone outside the team.

Incident runs. One bad deploy is absorbed. Three in a fortnight, each with a follow-up, take an engineer off feature work for weeks.

Support rotations that grow. A large customer goes live, escalations double, and the person on support duty stops contributing to the release at all.

Headcount is unchanged in every case. The team is busy, the board looks active, and the share of capacity left for the release has quietly fallen. That is a capacity change, the third of the three things that erode a committed release date. It rarely travels alone: the end-of-life upgrade often arrives with its own dependency on another team’s platform work, and somebody usually asks for “just a small fix” to be folded into the release, which is scope.

Keep the KTLO share. Read what a change costs the date.

The answer is not to fight KTLO or to hide it in a separate board. It is to state the assumption plainly and re-read it in days.

1. At planning, write down the KTLO share the team expects and the committed date with the confidence level the team voted at. Treat the share as an assumption the vote rests on.
2. Base the forecast on a throughput window long enough to include the team’s normal KTLO load, so the usual level is already in the numbers.
3. When a known KTLO pull-away starts (a named engineer on an upgrade for six days, an extra on-call week), record those days as time off against that person’s Jira account before the work starts.
4. If KTLO work is put into the release’s Fix Version, it is scope, and it should be forecast with the rest of the scope.
5. At every sprint boundary, read the gap in days between the committed date and the forecast at the committed confidence.

An illustration, not customer data. A release is committed for 4 December at 85% confidence. At the vote the 85% forecast sits at 30 November: four days of margin. In week three the driver upgrade takes two engineers for six working days each, recorded as time off against their accounts, and the patch queue behind it slows delivered throughput over the next two sprints. No issues were added to the release. The 85% forecast is now 11 December, seven days past the commitment. The 50% forecast is 2 December, so the release reads amber, not yet red.

Now the planning conversation has a number on it. Push the upgrade to January and accept the security risk for a month? Trim a Should-have at the MoSCoW cut-line? Borrow an engineer from a team with slack? Renegotiate the date while there is still margin to trade? Every option is the team’s call. What changes is that the call happens in week three, not at the demo.

Where Advanced Release Planning fits

Advanced Release Planning for Jira does not store a KTLO percentage or classify work as KTLO. It reads the inputs a change in KTLO actually touches. Time off is recorded per person, per day, against the Jira accounts assigned to the release’s issues, and public-holiday calendars are imported per team, both folded into the Monte Carlo forecast through the Capacity Awareness setting. The forecast is built on the team’s delivered throughput over the throughput window you choose, so the normal level of interrupt and maintenance work is already reflected; what it surfaces is a change from that level. A known pull-away recorded as time off reaches the forecast directly, earlier than waiting for it to show up in throughput; an unrecorded KTLO spike registers as later throughput data slows. Either way the committed date is re-forecast and the shift is reported in days against the 50%, 85% and 95% bands. The team sets the assumptions: which throughput window, whose capacity, what is in scope, what share goes to keeping the lights on. The app does the arithmetic at Monte Carlo scale and keeps it live. Green at or above P85, amber between P50 and P85, red below P50.

For the slow version of the same erosion, see why managing technical debt is a quiet tax on the date. For the constraints teams list at planning and stop reading, see resource constraints. For exactly what the app reads when capacity changes, see the capacity change tracking reference doc.

Key takeaways

• KTLO means keep the lights on: patches, upgrades, incidents, on-call and support that keep existing systems running.
• The KTLO share a team names at planning is expert engineering judgment and part of the evidence behind the confidence vote.
• Patch waves, end-of-life deadlines, incident runs and growing support load change that share after the vote, with no change in headcount or scope.
• Record known KTLO pull-aways as time off, keep the normal level in the throughput window, and read the gap in days at every sprint boundary.

FAQ

What does KTLO stand for?

Keep the lights on (sometimes “keeping the lights on”). In software it means the maintenance and operational work needed to keep existing systems running, as opposed to building new features.

What counts as KTLO work?

Bug fixes, security patches, dependency and infrastructure upgrades, incident response and on-call duty, and customer support escalations are the usual examples.

Does KTLO affect a committed release date?

Its normal level is already part of the team’s delivered throughput. A change in that level after the vote, such as an upgrade deadline or an incident run, reduces the capacity left for the release and moves the date. Read the shift in days against the confidence level the team committed at.

Keep the lights on. Keep the date honest too. See the committed date and its live confidence band in Advanced Release Planning, or start a free trial on the Atlassian Marketplace.

Rob Borges

Rob Borges spent the first half of his career hunting waste as a Lean Six Sigma Master Black Belt and wrangling portfolios as a PMI Portfolio Manager — until he realized the tidiest process on earth still can't out-plan an optimistic human. So he switched sides and became an Agile Coach. These days he helps Kanban, Scrum, and Agile-at-Scale teams trade gut-feel deadlines for flow data, turning "we'll probably ship sometime in Q3" into release dates leaders can actually take to the board. His rule of thumb: hope is not a forecast, but your throughput history usually is.

See Full Bio