Make-up Stories
Imagine our Product Owner says: “I want this feature by tomorrow, and I don’t care if you’ve got to hack it in – if we don’t deliver it tomorrow it will cost us millions of dollars!!” What do we do?
That’s a rhetorical question, I hope. Of course, we just hack it in – You intentionally create technical debt – because doing the “right thing” is not always the right thing to do. There could be a higher business value that overules quality, right? Now, I know that there are those that don’t agree with me here, but I certainly hope you’re not one of them 
But, then what? We’ve got this part of your code that’s just hacked in, sitting there stinking up the place. We’ve got to live your values. The scrum values I teach are openness, focus, commitment, courage, respect, and visibility (this is a non-standard list). The values that are relevant to this situation are respect and visibility; we must respect our product, and make it visible that we just created technical debt. By the way, I should have the same feelings even if I was the one to put in the technical debt, and it wasn’t the fault of my Product Owner
So, I recommend that we add a “make-up” story to the backlog; a story that apologizes to our code base and promises to fix it. For example, let’s say that what we did while hacking the code was forget the unit testing and create some badly designed code (in module XYZ) that needs re-factoring. Then, what we would do is add a story to the backlog named “Fix up Module XYZ” in which we would explain what unit testing needs to be done and what code needs to be re-factored.
This story serves two purposes. The first is that it formally admits that we left a mess behind, and can be thought of as an apology to our product. The second is that it forces our Product Owner to make conscious decisions in the future NOT to “Fix up Module XYZ” in order to add other features. The first purpose proves that we are living our values, and the second purpose forces the product owner to make active prioritization decisions of features versus quality.
Both of these purposes are in the best traditions of scrum, but the second might be the most important. We need to “force” our Product Owner to make active decisions (both good and bad) about what our system should be. I have found that passive decision-making is almost always bad for our product, and reflects the fact that “all that is necessary for the triumph of evil is that good men do nothing” (Edmund Burke, 1790)
Thanks, Dan ;-)
