Why on earth do we do that?
Team A, an Agile Release Train (ART), or the mythical Scrum team, has a lot of technical debt. In an effort to reduce the technical debt, management decides to create a bunch of new “container” “FEATURES” in the product backlog to address batches of defects. Because they want to understand the value of the (fixing) defects.
Except there is a problem. Defects are not new features. Well, in a sane software world we hope not? Defects are typically created while coding or configuring a new feature, right? Is it a defect yet? Not really. Fix it NOW, not later. If it makes it to production? What is the cause of defects making it to production? Poor coding, standards, quality and automation, et cetera? No DevOps? or do defects occur magically in existing features (real ones)? (not my code!!) We all know how computers have minds of their own…
I’ve seen that oddly familiar pattern of desire to package up defect fix/technical debt effort into a feature or story or a suite before. I call these “projects”, “probably to be implemented with waterfall.” That type needs project managers and factory workers, not Lean-Agile practitioners, creative knowledge workers driven by autonomy, mastery, and purpose.
7 wastes of Lean
Over-processing, transport, others here in the example. Lean-Agile teams allocate capacity for things like technical debt/bug squash, or whatever fits the strategy and tactics at play on the field.
SAFe recommends not using tasks.
Spending capacity to create/track phony stories or features is waste. Use enablers perhaps, maybe? Are there already tickets for the defects? It is hard to define the value for defects because independent defects don’t have value. Does a defect have value? Oh, wait, …. defects actually devalue software and systems.
Working software/systems have value (Agile Manifesto: P1, P3, and the biggie P7) and we must measure value objectively (see SAFe principles and values). Defects are crap!
It sounds like the ART is not BUILDING QUALITY IN to the system.