Testing

Code can express what we want to accomplish, but it’s a little more difficult to express why we’re doing something in the first place. The people who maintain code are often not those who originally wrote it, so documenting why helps set a context and gives clues as to what the author was thinking when they came up with a particular design, making developers' jobs easier.

Just as you should not take out a financial loan without having a plan to pay it back, you should also have a plan when incurring technical debt. The most important thing is to have transparency—adequate tracking and visibility of the debt. Armed with the knowledge of these pending tasks, the team can devise a strategy for when and how to “pay off” technical debt.

Releasing in small batches is a good way to achieve quick feedback in your sprints, but these pieces don't have all the features users need. Providing consumable value is turning those small bites into a meal, and it’s worthwhile to estimate what it will take to deliver that—asking, “What consumable value do we expect to achieve, what duration and cost should we plan for, and how likely is it that the plan will succeed?”

One of the benefits of agile is how it helps specify requirements. Instead of trying to predict the future with your requests, you can wait an iteration and see if more criteria are needed. This article gets into how executable specifications, specification by example, and test automation can help further improve your requirements management.