1. Replaced word “checklist” with “collection”.
why? - During my discussions with people, I have noticed that checklist has implied meaning which is beyond what was intended by the post. For traditional managers a checklist implies an order (sequence) and also a notion of “gotta do it”. I now feel that “collection” expresses my opinion better as it stays away from both of these traditional notions.

2. Replaced word “activities” with “deliverables”.
Why? - Initially the first point stated that ‘DoD is a checklist of activities…’ This could have been better stated as ‘DoD is a collection of deliverables..’ since by calling these as activities I inadvertently strayed into implying the ‘how’ rather than the ‘what?’. The team through its inspect & adapt cycles is ultimately responsible to figure out the ‘how?’

Yes, simplicity is a virtue. If you feel there is a redundancy, talk to the team about it. See if the item intends to assert same aspect for quality of software. Go with the team’s consensus. After all, DoD is an tool/artifact to help the team develop quality software at the end of each iteration/sprint.

~ Dhaval

Thank you for explanation, it was very helpful. I would like also your opinion on a different matter. When defining DoD’s on different levels some redundancy can be created. For example the DoD for a feature can contain the following criteria:

- Code has to be unit tested

And the DoD for a sprint can have the criteria:

- All stories should be unit tested.

But the first criteria implies the second. Should this redundancy be removed or is it still useful on the sprint DoD?

I agree after “Step V: Share Values”, information gathered can be processed in different ways

a) Brainstorm to create items for a working agreement. These items may not be sufficient to capture all aspects of working together, probably the cooperation angle.

b) Do affinity grouping of similar items to rationalize the number of shared value statements.

c) Affinity grouping with previously created items to focus on persistent trends.

You also raise a good question - should a working agreement be enforceable? - I’ll save that for another entry..

Thanks for guiding me beyond the obvious.

cheers!
Dhaval

Sure, there will be different set of tasks for different features. Capturing all tasks for all possible features in DoD will be overwhelming. Suggest elevating these tasks (eg: “test ui for valid e-mail entry”) to something more generic (eg: “acceptance test”).

DoD helps to guide our thinking so that we can generate appropriate tasks for a feature. Acceptance testing for a feature that has ui elements, will need different tasks than acceptance testing a feature that updates database. However, the commonality lies in validating: Does this feature do what it is supposed to?

Thank you for your comment Dennis, I hope this was helpful.

cheers!
Dhaval

A few thoughts:
1) You could do a brainstorming exercise after all of this where you create items that are S.M.A.R.T. for inclusion on the working agreement. I feel that a working agreement needs to have items that are Small, Measurable, Achievable, Repeatable(?), and Tom-like(?). OK, maybe just the first three. A working agreement that only contains value statements…hmmm…is it really enforceable? should a working agreement be enforceable? I think so.
2. I’m not sure where I would see this going over time, but It would be interesting to see if there were certain affinity groups that were persistent.

Great topic!
-Tom