Blog
Mert Özen's blog posts on software development, backend, frontend, and DevOps.
What Is Scrum? Empiricism, Lean Thinking and the Problem Scrum Solves
Scrum is a purposefully incomplete, lightweight framework for generating value in complex problems: three accountabilities, five events, three artifacts and one commitment per artifact. The post explains the three pillars of empiricism, lean thinking and the five values through the Bookstore team's first Sprint preparation, and shows that velocity, story points, user stories and the three Daily Scrum questions are not in the Guide.
The Scrum Team and Its Accountabilities: Product Owner, Scrum Master and Developers
In the Scrum Guide 2020 there is a single Scrum Team with three accountabilities: a one-person Product Owner who maximizes value, a Scrum Master accountable for the team's effectiveness, and Developers, testers, DevOps and designers included, who create the Increment. The post covers the shift from roles to accountabilities and from Development Team to Developers, and the traps of a Product Owner committee, proxies, separate QA teams and secretary Scrum Masters, using the Bookstore team.
The Product Backlog and the Product Goal: What We Build and Why
The Product Backlog is the ordered, emergent list that is the single source of the Scrum Team's work; its commitment, the Product Goal, says why the list exists. The post shows how ordering weighs value, risk, dependencies and the cost of waiting, why refinement is not an event, and when a Definition of Ready, which is not in the Guide, becomes a gatekeeper, using Bookstore's GitHub Projects backlog.
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.
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 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.
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.
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.
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 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.
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.