A definition of done is one of the cheapest and most effective ways in which you can start tackling IT issues. It can improve quality, transparency, accountability, alignment, and even predictability. All at the cost of a conversation and some documentation.
There’s plenty of material on what a definition of done looks like and why you might want one, but not much on how to go about constructing your own. This is my attempt to fill that gap.
An article I recently wrote on Agile Test Data Management prompted some responses on a more fundamental level. What is Agile testing? There are plenty of methods, frameworks, and comprehensive guides available that will provide you with a template for Agile testing. Unfortunately, most of these are either too prescriptive or thinly-veiled waterfall anyway.
This isn’t one of those, this will be a quick dive into the principles that might help you evolve your own practice.
It’s likely a coincidence, but I’ve recently noticed a slew of issues arising in my work around test data management. As I dug into this, I found a disappointing lack of prescient information on how to manage this in an Agile environment. It’s going to be a quick one this week, but here’s my take on agile test data management.