Agile - Definition of DONE
By Ray Claridge
Having worked in agile development for a while now, one inconsistency that I always come across is the definition of DONE.
Some say this should be when a user story has passed UAT and signed off by the product/business owner. Others say after the functionality is tested and passed by the assigned tester. Personally I agree with the latter. Let me explain...
Development and testing tasks for each user story are completed by the development team. The team commits to the workload at the beginning of each sprint and are responsible for delivering the user stories to the product/business owner for UAT. Once delivered, the team have no control as to when UAT starts and finishes.
Where the development team's primary job is the develop & test, more often the person responsible for UAT has to fit this around a full time job as and when they find time. With this in mind, it might be difficult and unreasonable to expect sign-off before the sprint finishes. Also, this person is not responsible for delivery, nor part of the sprint commitment process. Therefore, I believe it's unfair to include UAT before you can say a story is DONE.
Here's my take on when something is done (including development & defects):
Ray
Nice definition Ray.
I'd pretty much agree with that, but it's fair to say that the DoD is very much a team and project specific choice.
Some projects we run have about 20 or 30 factors involved in the DoD.
It can get very very complicated quickly. I'd totally agree - it's inconsistent and creates a whole world of disagreement sometimes :)
Rob..
This is a tough one, Done like beauty all depends on who's looking and I believe this veers away from the essence of Agile. My experience of Done is a bit like the baton in a relay race, each leg considers job Done as long as the baton has been passed on but the whole team gets a Gold, Silver or a Bronze medal. Agile focuses on joint ownership, cross functional teams, iterative development with regular feedback. Done should only represent one thing, satisfying the customers needs. Until a need has been satisfied (the finishing line has been crossed) I really don't think Done (the teams commitment) is Done.
I've sat in hour long retrospectives where 'Done' has been the hot topic and the 'customers need, request' has been lost in translation.
I've been the leader of a scrum team for a little over a year now and the DoD is something I've continued to struggle with. For some time we would simply validate that a list of acceptance criteria - taken from the use case - had been met and consider a story DONE. Now I am considering including a set of tests - automated where possible and manual where not - where these become the acceptance criteria.
Has anyone else adopted a similar approach and what kinds of results did you see? I'm concerned that this level of testing to consider a story DONE will greatly slow down our team velocity, but am hopeful that it will increase our confidence in the quality of the software. It should also help us to generate a repository of regression tests.