4squareviews

The last post covered process 3.6 Iteration Backlog, where negotiating is done between the customer-proxy and the team as to what user stories the team is committed to completing by the end of the iteration.

Part of that negotiating exactly contains the process that is the subject of this post, 3.7 Definition of Done,

Okay, let’s say that the team completes all of the user stories to its satisfaction by the end of the iteration.   All’s well, right?   Well, not if the customer looks at the work and declares that it isn’t done to the customer’s satisfaction.   That’s where the Definition of Done comes in.

It lists all of the specific activities to be finished and all the tests to be done so that a specific user story can be said to be complete.   It’s important to list this out in an explicit and concrete manner so that they can be misunderstanding at the end of the iteration between the team and the customer/proxy.

Sometimes creating an appropriate definition of what “done” means can be a lot of work, but cannot be avoided or done sloppily, because it will create the potential for results that are disappointing and frustrating for both parties.   This means that there will have to be rework done, which wastes time and personnel resources, but it also damages the relationship of trust between the parties, and that is the real “currency” that the project rests upon.

After a brief break tomorrow for a post on another topic, I will return two days from now with a series of posts on processes 3.8 and 3.9 Estimation and Sizing.  These processes are at the heart of agile estimating and I look forward to tackling them, which may take several days worth of posts.

Filed under: Uncategorized |