Blog
Mert Özen's blog posts on software development, backend, frontend, and DevOps.
Scrumban and the Kanban Guide for Scrum Teams: Adding Flow to Scrum
Adding flow to Scrum doesn't require dropping the Sprint: the Kanban Guide for Scrum Teams adds a DoW, WIP limits and the four flow metrics to Sprint Planning, the Daily Scrum, Review and Retrospective without changing any part of the Scrum Guide. We cover Scrumban as Ladas described it, as a transition path, its loose use today, and choosing Scrum, Kanban or both for support, platform and product teams.
Actively Managing Flow in Kanban: Blockers, Aging and Flow Reviews
Actively managing flow means reading the board right to left from the oldest item every day, escalating blocked work, limiting expedite and finding the bottleneck with data. We compute CFD band widths from Bookstore data in C#, see how Code Review became the bottleneck in July, how the Theory of Constraints steps solved it (p85 from 16 to 11 days), and why the next constraint is the deploy rhythm.
Service Level Expectation and Monte Carlo: Answering "When Will It Be Done?" with Probability
For a single item the answer is the SLE ("85% within 14 days"); for many items it is a Monte Carlo simulation that samples historical daily throughput. Running 10,000 times on Bookstore data, our C# code says 30 items finish by 25 November with 50% probability and by 6 December with 85%. We cover reading percentiles from the right end, explaining forecasts to stakeholders and when the forecast goes wrong.
Flow Metrics: WIP, Throughput, Work Item Age and Cycle Time
We compute the Kanban Guide's four mandatory metrics, WIP, Throughput, Work Item Age and Cycle Time, from six months of the Bookstore team's board data with a .NET 10 console app. We see why percentiles beat the average, how to read a cycle time scatterplot and an aging chart, why Work Item Age is the earliest warning, and how measuring from the Created date turns a p85 of 14 days into 79.
WIP Limits and Little's Law: Start Less, Finish More
With throughput fixed, raising WIP stretches cycle time by the same factor; Little's Law is the arithmetic behind it. In our C# simulation, raising WIP from 3 to 10 takes average cycle time from 2.4 to 7.9 days, and adding context switching cuts throughput too. We cover Little's Law's assumptions, why it is not a forecasting tool, how to set a first WIP limit and pitfalls like per-person limits.
The Definition of Workflow and Board Design: When Work Starts and When It Finishes
What turns a board into Kanban is the Definition of Workflow behind it: the work item definition, started/finished points, states, WIP control, explicit policies and an SLE. We build the Bookstore team's board from these six parts, separate queue and active states, show how tying Done to the production deploy instead of the merge changes cycle time, and cover common board design mistakes.
What Is Kanban? From Toyota to Software, and Why It's More Than a Board
Kanban is not a board but a strategy that optimizes the flow of value by limiting WIP; the board only makes it visible. Using the Bookstore support team's board, we trace the path from Toyota's pull system to Anderson's work at Microsoft and Corbis, compare the Kanban Method with The Kanban Guide 2025.5, and introduce the Guide's three practices and four flow metrics.
The Evolution of Scrum: From the 1986 HBR Paper to the 2020 Guide and the 2025 Expansion Pack
As of November 2026 the official definition of Scrum is still the Scrum Guide 2020; the Expansion Pack published in 2025 by Sutherland, Jocham and Coleman (latest v2026.1) does not carry Schwaber's signature and does not replace the official Guide. The post traces the path from the rugby approach of the 1986 HBR article through the 1995 OOPSLA presentation and the 2010-2017 revisions to the Product Goal, commitments and self-management of 2020.
Scrum Anti-Patterns: Dark Scrum, Zombie Scrum and Mini-Waterfall Sprints
What Scrum anti-patterns have in common is that empiricism is not working while the events and artifacts are in place. The post brings Dark Scrum, Zombie Scrum, ScrumBut, Sprint 0, hardening sprints, mini-waterfall and carry-over Sprints into one table of symptom, root cause, what the Guide says and first step; it shows that most stem from large items and a weak Definition of Done, and gives teams a 10-question self-check.
Engineering Practices in Scrum: Branching, CI, Feature Flags and Technical Debt
Scrum imposes no engineering practices, but a Done Increment every Sprint is only sustainable with short-lived branches, CI and feature flags. In a real run with Microsoft.FeatureManagement 4.8.0, the return endpoint returned 404 with the flag off and 201 with it on; the same build behaved differently in two environments. The post explains why a flag does not pierce the Definition of Done, three ways to make technical debt visible, and spikes.
Scrum Metrics: What Velocity, Burndown and Sprint Goal Success Do and Don't Tell You
The Scrum Guide defines no metrics; velocity, burndown and Sprint Goal success help the team's own forecasting but do not show value. In a real C# run, the burndown of a Sprint whose scope grew by 3 items mid-Sprint sits at 12 on day four, the same as at the start, while the burnup shows progress and the scope change separately. The post also covers comparing velocity across teams and Goodhart's law.
Sprint Review and Sprint Retrospective: Inspecting the Product and the Process
The Sprint Review is not a demo but a working session in which stakeholders inspect the Increment and the Product Backlog is adapted; the Retrospective inspects individuals, processes, tools and the Definition of Done and puts a measurable improvement into the Sprint Backlog. The post covers Bookstore's 90-minute Review agenda, retro formats, and an action that cut code review waiting time from 2.1 days to 0.6 days.