Illustrative examples only — provided “as is”, with no warranty or liability on our part. Use one to see how to frame adaptive delivery and what the questions are for, then build your own with your team’s real throughput.
$ iziRisk Mobile banking app About 180 stories are left in the backlog for our mobile banking app, delivered by two squads on two-week sprints. Payments has closed 9, 12, 7, 11, 14 and 8 items in its last six sprints; onboarding has closed 6, 9, 5, 8 and 7. Onboarding cannot start its integration work until payments ships the API. Roughly one story in five splits in two once we look at it properly, and each sprint there is about a 30% chance a senior engineer is pulled onto a production incident for most of the sprint. We committed to launch in 14 sprints at a burn of 95,000 per sprint per squad. Will we make it, and what should we promise instead?
iziRisk E-commerce replatform We are replatforming a retail storefront: 240 remaining items, one team of nine on two-week sprints, recent throughput 14, 11, 17, 9, 13, 16, 12. Every migrated category reveals more work — we reckon each completed item creates about 0.15 of a new one. There is a hard freeze over the November peak that costs us one full sprint, and a 20% chance per sprint that a third-party payment integration blocks us for half a sprint. The board wants to know the probability of cutting over before the freeze, and how much scope we would have to drop to make it.
iziRisk Analytics platform migration Migrating 130 reports and 40 pipelines onto a new data platform. One platform team on weekly cadence has completed 5, 8, 4, 7, 6, 9, 3, 6 items per week; a separate analytics team of 4 can only start once the ingestion layer is live, and has historically done 3 to 7 items a week. Data-quality findings keep adding work — roughly 0.2 new items per item finished. The finance close in month five is immovable. Give me the finish distribution, the probability of being ready for the close, and which team is actually setting the date.
iziRisk Insurance claims portal A claims self-service portal with 160 stories left, one squad on three-week sprints, throughput 12, 15, 9, 14, 11, 13 over the last six. Two of those sprints were disrupted by regulatory rework we did not plan for, and we expect one or two more such interruptions before we finish, each costing roughly a sprint of capacity. Around 25% of remaining items are epics that will split into three. Budget is 1.6 million at 130,000 per sprint. What is the probability we deliver inside both the 12-sprint deadline and the budget?
iziRisk Core system modernisation We are strangling a 20-year-old core system: 320 known items across three streams — extraction, new services, and decommissioning. Extraction has run at 8, 6, 11, 7, 9 items per two-week sprint; new services at 10, 13, 8, 12, 11; decommissioning cannot begin until extraction is complete and has no history at all, so assume something like 5 to 12 a sprint with a slow start. Discovery on this codebase is brutal — closer to 0.3 new items per item done. There is no fixed deadline; leadership wants to know when this realistically ends and what it costs at 210,000 per sprint across the three teams.
iziRisk SaaS multi-tenant onboarding Building multi-tenant onboarding for our SaaS product: 95 items remaining, one team on two-week sprints with throughput 7, 9, 6, 10, 8, 7, 11. The team is two people larger than it was three sprints ago, so early history understates it. A new tenant type discovered mid-build would add 20 to 40 items — we put that at 40% likely. We promised the first enterprise customer a go-live in eight sprints. How exposed is that promise, and what does the probability of on-time delivery look like if we hold the extra scope out?
iziRisk Regulatory reporting, fixed date A regulatory reporting build that MUST be live on a statutory date 10 sprints away — there is no negotiating it. 140 items remain; the team has delivered 11, 14, 9, 13, 10, 12, 15 per two-week sprint. Requirements clarifications from the regulator have added about 0.18 items of new work per item completed, and we expect two more clarification rounds, each eating roughly half a sprint. What is the probability of being ready on the statutory date, how much scope must be cut to reach 90% confidence, and how early would we have to add a second team for it to help?
iziRisk Patient portal A hospital patient portal: 110 remaining stories, one team on two-week sprints, recent throughput 8, 6, 10, 7, 9, 5, 8. Clinical sign-off is the bottleneck — roughly a 35% chance per sprint that review feedback costs us half a sprint of rework. Integration with the records system is a separate stream of 45 items that cannot start until the vendor delivers their gateway, expected in three sprints but with real slippage risk. We are budgeted for 18 sprints at 78,000 each. Give me the finish distribution, the probability of finishing inside budget, and which stream is driving the date.
iziRisk Telecom self-service app Self-service app for a mobile operator: 200 items left across two squads on two-week sprints. The app squad has done 13, 16, 10, 14, 12, 15; the billing-integration squad 7, 5, 9, 6, 8 — much slower because every change needs a billing-system release window that opens every second sprint. About 15% of items split in two. Marketing wants launch aligned to a campaign 16 sprints out. What are the odds, and would moving people from the app squad to billing actually help or just add coordination cost?
iziRisk Game content pipeline Content pipeline for a game launch: 260 assets remaining, three pods on weekly cadence with throughput 12, 18, 9, 15, 20, 11, 14 combined. Art review rejects and returns roughly 20% of assets, which is effectively new work created per asset completed. Two pods share one technical artist, so when they both need them the second one waits — historically about one week in four. The launch window is 22 weeks out and slipping it costs a whole seasonal cycle. What is the probability of hitting the window, and how much content would we need to cut to be 80% confident?
iziRisk Internal developer platform An internal developer platform with 85 items left, one team on two-week sprints, throughput 6, 9, 7, 5, 8, 10, 6. The team is also on support rotation — roughly 30% of every sprint disappears into interrupt work, and that is already inside the numbers above. Adoption feedback from other teams keeps generating new requests at about 0.25 items per item delivered, which is the whole reason this never seems to end. There is no deadline. I want the finish distribution, an honest read on whether this backlog ever closes, and what happens if we cap the intake.
iziRisk Security remediation programme Remediating 310 security findings across four application teams on two-week sprints. Combined recent throughput was 22, 28, 19, 25, 31, 24 findings per sprint. Penetration testing every third sprint adds new findings — historically about 0.22 new per finding closed — so the backlog has grown twice already even while we were closing items. The audit committee has set a 12-sprint deadline. What is the probability of clearing the backlog in time, does it converge at all at the current discovery rate, and what throughput would we actually need?
iziRisk Support queue on Kanban Our platform support team works a continuous Kanban board — there are no sprints to count. 240 tickets and small defects sit in the queue today. Over the last ten weeks we closed 14, 9, 17, 11, 8, 15, 12, 19, 10 and 13 of them. Cycle times on the last ten closed items were 4, 6, 3, 12, 8, 5, 21, 7, 9 and 35 days, and we typically have about nine items in progress at once. New tickets keep arriving at roughly 0.45 per ticket we close. Management wants a service level we can put in writing and a date the current queue is cleared. What can we honestly promise per ticket, does the queue ever clear at this arrival rate, and do our throughput, cycle time and work-in-progress numbers even agree with each other?
iziRisk Data-centre exit to cloud We are migrating 420 workloads out of a data centre whose lease ends in 18 two-week sprints and will not be renewed. Two migration squads have got steadily faster as the tooling matured: the first did 8, 11, 14, 19, 22 and 26 workloads per sprint, the second started three sprints later and has done 5, 9, 12 and 15. About one workload in six turns out to be two once we open it up, and roughly 10% of migrated workloads come back for rework. Each squad costs 120,000 a sprint. Our early history clearly understates what the teams can do now — how should we forecast a team that is still improving, what is the probability of being out before the lease ends, and how much would a third squad actually buy us?
iziRisk Contractors rolling off A warehouse management rollout with 190 items left, one team on two-week sprints. Recent throughput was 15, 18, 13, 16, 14 and 17 — but five of our fourteen people are contractors whose engagement ends after sprint 3, and there is no budget to extend them. The nine who remain have never delivered on their own; my guess is 8 to 11 items a sprint afterwards. Roughly 15% of the backlog will split in two. The deadline is 14 sprints, and we are spending 210,000 a sprint now, falling to 135,000 once the contractors leave. What does the finish look like with that cliff in it, how wrong would we have been to forecast from the history alone, and would keeping two contractors for three more sprints pay for itself?
$ iziRisk Startup runway We have 150 items in the backlog for our first paid release and 11 sprints of runway — 1.4 million left at about 128,000 a sprint, with no further funding until we ship it. One team on two-week sprints has completed 12, 9, 15, 11, 13, 8 and 14. Sixty of the 150 items are must-haves and the rest are what makes it sellable. Discovery has been running at about 0.12 new items per item finished. The question is not really when we finish — it is how much of this backlog is done when the money runs out. Give me what is realistically delivered by sprint 11, the probability the 60 must-haves are done by sprint 8, and what we would have to stop doing to make that near-certain.
iziRisk Fraud-detection ML build A fraud-detection platform built by one research-heavy team on two-week sprints, with 90 items left. Throughput swings wildly because some items are experiments rather than features — the last eight sprints were 2, 9, 1, 7, 12, 3, 8 and 0. About one experiment in four is a dead end whose work is thrown away and attempted differently, which shows up as new items rather than as a slower sprint. Model validation by the risk function happens every third sprint and costs us roughly half a sprint each time. The executive committee has been told “about six months”, which is 13 sprints. What is the honest finish distribution with this much variability, how does the P80 compare with the promise, and how much does an average velocity hide here?
iziRisk Outsourced build, in-house UAT An integrator is building our new dealer portal: 260 items remaining, and their two squads together deliver 16, 13, 19, 15, 17 and 14 items per two-week sprint. Nothing counts as done until it passes our own acceptance testing, and our UAT group is four part-time business users who have accepted 9, 6, 11, 7 and 8 items a sprint. Around 12% of items fail acceptance and come back for rework. The contract carries a penalty for every week past a 16-sprint date. Which side is actually setting the date, what is the probability we pay the penalty, and would funding two more testers be cheaper than paying the integrator to keep running ahead of us?
$ iziRisk Post-merger consolidation Consolidating the systems of two merged banks: 540 items across five product teams on two-week sprints, on recent form delivering 9, 12, 7, 11 and 10 items per sprint respectively. Everything from all five has to pass through one shared integration and regression environment, which has never processed more than about 30 items in a sprint and is usually nearer 22. Regulatory approval of the combined entity is 20 sprints away, and we are spending 480,000 a sprint across all the teams. Adding people to the product teams is easy; adding capacity to the environment is not. What is the probability of finishing before the approval date, how much of this work is simply queuing, and what happens to the date if the shared environment doubles its capacity?
iziRisk Half-catalogued legacy migration We are retiring a 30-year-old policy administration system, and the honest problem is that we do not know the size of the job. We have catalogued 310 items so far, and the analysts believe that is around 60% of it — so the real total is somewhere between 420 and 560. One team on two-week sprints has completed 11, 8, 14, 10, 12 and 9. Every interface we open adds a little more, call it 0.1 items per item finished, on top of the uncatalogued work. The business wants a date to give the regulator, 18 sprints out, at a budget of 165,000 a sprint. How do we commit to anything when the denominator is a guess, what does the forecast look like across that range, and would three more sprints of cataloguing be worth it before we answer?