what's remaining allowing us to focus on the next iteration. We told ourselves that we are done, but we know that we are not completely done.
Changing to the mind set of completely done is not easy. In most circles people think that this only applies to the software developers. Managers find it easy to ask "are we done yet" but fail to realise they are also a part of this message. They should be able to see clearly and be part of the progress without asking and have confidence in what they see, after all our GPS route system constantly informs us with elapsed journey time and estimated arrival time displayed on it's screen all the while through our journey. We never stop, get out our calculator and double check the numbers, we trust what we see. The information radiates out to us and we are kept warm in the knowledge that all is fine.
Knowing that we are completely done requires one key piece of information, our criteria for a successful outcome . If we do not know this then we cannot even claim that we are done. This doesn't just mean that there are no defects in the code, or that we haven't broken existing features, it means that the features are also fully satisfying the needs of the customer . Even if we do express our requirements as user stories or use cases we often fail to provide acceptance criteria. If we did then we would know for each requirement whether we were able to achieve a successful outcome. Continuous automated testing against these outcomes would then start to show us how far we had come, and how far there was to go just like the GPS route system without the reliance on prediction models.
Part two of this article will focus on our criteria for a successful outcome, how we express this in the context of software and will uncover the loophole many agile teams overlook. Part three will then demonstrate how this can overcome and transferred into our code so that we can deliver shippable code.
About the Author