Manifesto of Done

Heres what I have posted on another forum, and it's the start of a thought; rather than the finalisation.  I have been thinking about this for sometime, in Agile we bang on about the concept of "Done" but it's very rare do we actually outline what this would actually mean.  So I came up with the following; however, Bob McNeal, actually pointed out that this more Dev Team Contract than a Manifesto of Done. Reviewing it I kind of agree.  So what I need to do is come up with some way that moves this to a Manifesto of Done.  Maybe I need  a Product Owner to Dev Team Contract, a Dev Team Contract, and  Customer to Dev Team contract.  And maybe these will then implicitly create the manifesto of Done.

I will keep you posted.

This is the Original Post.

Here is what I am proposing to my team as something that we all subscribe to. So over to you my learned and estime colleagures for a critique.


• I will make sure that my code is usable. My code is for use and interaction with other people, and everything I write must make this a pleasurable experience, and reduce workload not increase it.



• I will make the code I write confirm to the style agreed by the team. People other than myself, will be maintaining and amending my code. So while I have flexibility to design and utilise any technology to build my solution. Abiding by the standard while I write this code will allow others to maintain my code.



• I agree to keep my methods to a reasonable size. Large methods are difficult to navigate, and make difficult to debug. As far as possible I will keep my methods to a reasonable size to alleviate this complexity.



• I will comment all code. Whether I am creating new code or altering existing code; I will make short but succinct comments to explain what I have done. So that others reading the code after me understand what I have done and what the code is trying to achieve.



• I agree to unit test my code. I agree to make these tests re-usable and not brittle. I will make the test explain what it is testing and why. So not only will others be able to run my tests when they refactor or fix bugs; they will also be able to see what my code was trying to achieve.



• I agree to maintain the unit tests for existing code. When I alter or add new features to existing code, I will make sure that all the tests pass and that there are new ones for any new feature.



• I agree to try to get my code coverage to at least 80%. By checking my code coverage I will make sure that everything I write has value. That there are no surprises’ in my code that could cause problems later. I will endeavour to get this figure higher.



• I agree to check my code integrates correctly. When I have finished writing my code I will work with the other developers working on my feature to make sure that my code works well with all the other code and that it delivers the requested functionality.