OK, let’s say you’re on a Scrum team that’s planning its next iteration. You pull a story to implement Feature X for the next release of Application Y. You review the specs, maybe have a conversation or two with the product owner to clarify a few details, and discuss implementation details with your team lead. Cool. Now, you design the feature, code it up, build it and tweak it until its working to your satisfaction.

Then you check it into the source control system and move on to the next feature. Done, right? Not necessarily so! Sure, you can stand in front of the users at Sprint Review and watch them salivate as you demonstrate Feature X in action. But, can they walk out of the review and begin using it right away? Most likely not. If not, is it really done?

“Code complete” is just one milestone on the yellow brick road to Emerald City, where users are happily whistling away while using your excellent Feature X in their Application Y. There is so much more to consider. What about unit testing? Integration testing? Acceptance testing? Documentation? Packaging? Deployment?

Getting an application successfully delivered involves much more than working code. Failure to take this into account, and considering “code complete” to mean the same thing as “done”, inevitably causes a development team to fall behind schedule as they scramble to deliver what was already considered done. This is a form of technical debt, a topic I’ll explore in a future post.

For more information on the meaning of “done”, check out this excellent podcast on HanselMinutes.com:

What is Done? – A Conversation with Scrum Co-Creater Ken Schwaber