Blog
Mert Özen's blog posts on software development, backend, frontend, and DevOps.
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.
The Increment and the Definition of Done: What "Done" Really Means
The Definition of Done is the Increment's commitment: an item that does not meet it can neither be released nor shown at the Sprint Review, and returns to the Product Backlog. The post writes a concrete Definition of Done for a .NET and Angular team and turns it into a GitHub Actions workflow: in a local run of its steps a vulnerable transitive package broke the build with NU1903, and an uncommitted OpenAPI document made git diff exit with code 1.
The Daily Scrum: A 15-Minute Planning Event, Not a Status Report
The Daily Scrum is a 15-minute planning event in which the Developers inspect progress toward the Sprint Goal and adapt the Sprint Backlog; its output is an actionable plan for the next day, not a report. The post covers why the three questions were removed in 2020, a format that walks the board from right to left and looks at item age, practices for remote and hybrid teams, and the traps of reporting to managers, problem solving and overruns.
The Sprint and Sprint Planning: Why, What, How and the Sprint Goal
A Sprint is a fixed-length event of one month or less; Sprint Planning produces the Sprint Goal and the Sprint Backlog through the why, what and how topics. The Developers commit to the Sprint Goal, not to the selected items, which are a forecast. The post shows good and bad Sprint Goals, why only the Product Owner can cancel a Sprint, and the Bookstore team's real capacity calculation, which comes to 72 percent of gross capacity.