How much of the week
is already under water?
Set your team size and incoming load. Scrub the weeks to see release tests and the tickets that follow. The big number is the time left for product. Every result below comes from an explicit model, not a benchmark or a quote.
of 320 team hours · nominal, before meetings
Of your team's nominal capacity absorbed by maintenance this week.
Product target: 192 h/week (60% · model assumption)Includes the fix.
Of baseline weekly inflow; arrive over the next two weeks.
Separate from handling and fixes.
A dedicated stream of 5 people, sized to your inflow.Additional paid capacity. Average load: 171.5 h/week; peak: 185.3 h/week.
1 release this week · 4.5 extra tickets from earlier releases
- Tickets, including fixes
- 161.3 h
- Regression tests
- 24 h
- Left for product
- 134.8 h
Water depth shows the share of your week used by maintenance. The dashed mark leaves 60% for product. FTE = one person's 40-hour week. Values are rounded for display.
What keeps slipping off the roadmap?
28.3FTE-weeks of product backlog
as-is, by week 26
Each week below the 192 h product target adds unfunded work. This chart adds those shortfalls; it does not assume that a later quiet week pays them back.
The offload line is zero because the model removes all maintenance from this team and reserves only 60% for product. It is an upper bound on capacity recovered, before handover, meetings and other work.
Read all 26 weeks as a table
| Week | As-is | Offloaded |
|---|---|---|
| 1 | 1.2 | 0 |
| 2 | 2 | 0 |
| 3 | 3.4 | 0 |
| 4 | 4.2 | 0 |
| 5 | 5.7 | 0 |
| 6 | 6.5 | 0 |
| 7 | 7.9 | 0 |
| 8 | 8.8 | 0 |
| 9 | 10.2 | 0 |
| 10 | 11 | 0 |
| 11 | 12.5 | 0 |
| 12 | 13.3 | 0 |
| 13 | 14.1 | 0 |
| 14 | 15.3 | 0 |
| 15 | 16.1 | 0 |
| 16 | 17.5 | 0 |
| 17 | 18.4 | 0 |
| 18 | 19.8 | 0 |
| 19 | 20.6 | 0 |
| 20 | 22.1 | 0 |
| 21 | 22.9 | 0 |
| 22 | 24.3 | 0 |
| 23 | 25.2 | 0 |
| 24 | 26.6 | 0 |
| 25 | 27.4 | 0 |
| 26 | 28.3 | 0 |
How this model works
The week has a limit
Team hours = people × 40, nominal, before meetings. Ticket hours = (baseline inflow + that week's extra regression tickets) × handling time. Handling includes the fix. Tests are charged once, in the release week: release count × test hours per release.
Releases create a tail
We place 12 releases evenly across 26 weeks, starting in week one. Each adds weekly inflow × regression percentage tickets, split equally across the next two weeks. Overlapping release tails add together. Fractional tickets represent expected workload.
0 modeled regression tickets fall after week 26 and are outside this chart.
Shortfall, not a debt forecast
Product hours = max(0, team hours − ticket hours − test hours). Overflow = max(0, maintenance − team hours); it is shown separately, without automatic carryover. Product demand = 60% of team hours. Backlog starts at zero and adds max(0, demand − product hours) each week; divide by 40 for FTE-weeks.
Staffing has a cost
Dedicated people = ceil((average ticket hours + average test hours/week) / 40), averaged over this horizon. Peak cover is separate. Offload transfers the entire stream immediately. No prices, ramp-up, coordination cost, compounding debt or reduced regression rate are assumed.
The work keeps arriving.
Give it a place to go.
For Ranorex, Pirxey handles a maintenance stream that includes customer reports and compatibility fixes for new operating-system and browser versions. That is the kind of ongoing ownership we mean. The examples here describe the work, without disclosing client volumes or outcomes.
A customer report needs an answer.
Collect enough detail to reproduce the problem, decide what needs attention and work through the fix. Keep the report connected to its resolution so the next person does not have to start again.
Every fix needs a way to stay fixed.
Check the changed behavior and nearby paths that could break. Keep regression coverage useful as the product changes. A closed ticket is more valuable when the same issue does not reopen next release.
The platforms around you keep moving.
A browser or operating-system update can break working software without a product change on your side. Track compatibility, reproduce failures and prepare the fixes that customers need.
Recurring problems deserve a planned fix.
Repeated reports can point to a deeper problem. Record that pattern and agree which underlying fixes belong in the maintenance stream. Your team keeps product priorities; we help give the recurring work consistent attention.
The load is real.
Its size is specific to your product.
These are historical survey results, observational data and our own commit history. Hours, bugs and commits are different measures. None of the percentages below is used as a coefficient in the calculator.