Week 13 Day 2: Every Task Either Creates Value or Protects Value

Value creation is the work that grows the business -- new features, new customers, new capabilities. Value protection is the work that prevents the business from shrinking -- bug fixes, security patches, infrastructure maintenance, compliance. Both are essential. The problem is when a team cannot classify their work into these two categories, because that means they are doing work that neither creates nor protects value.

This framework eliminates an entire category of debate in sprint planning. When someone proposes a task, the first question is: 'Does this create value or protect value?' If it creates value, the follow-up is 'for whom, and how much?' If it protects value, the follow-up is 'what breaks if we do not do this, and when?' If the answer to both is 'I am not sure,' the task needs more definition before it enters the sprint. I used to let vague tasks into sprints because pushing back felt confrontational. The result was that the team spent significant time on work that produced no measurable outcome. When I started requiring every task to have a one-sentence value statement -- 'creates value by reducing onboarding time from 15 minutes to 3 minutes' or 'protects value by preventing the authentication service from exceeding its rate limit' -- the sprint became 40% more focused without any increase in effort.

The creates-value-versus-protects-value distinction maps to what March (1991) called 'exploration' versus 'exploitation' in organizational learning theory. Exploration (value creation) involves search, experimentation, and risk-taking. Exploitation (value protection) involves refinement, efficiency, and execution. March argued that long-term organizational survival requires a balance between the two, but that most organizations default toward exploitation because it produces more predictable short-term returns. In software development, this tension manifests as the perpetual debate between new features (exploration) and technical debt reduction (exploitation). Research by Besker, Martini, and Bosch (2018) on technical debt found that development teams spend an average of 23% of their time managing technical debt -- which is value-protection work -- but that this percentage is rarely visible to business stakeholders because the work is not classified in value terms. The one-sentence value statement requirement described in level_2 is a simplified version of impact mapping (Adzic, 2012), which traces every deliverable back to a business goal through a chain of actors and impacts.