The tasks for a story are “owned” by the team; the team commits to stories, not tasks. The tasks only exist to aid the team in its development efforts – it is the “doneness” criteria that define the “contract” for the story, not the tasks. Generally speaking, it is nobody’s concern except the team’s who works on what task, or even what the tasks are.

* Coded – it works on the developer’s box
* Verified – Unit tested and they work on Integration box
* Validated – accepted by ProductOwner as being what was needed

Later on a fourth “Done” was added for “Production Ready”, which meant:

* Production Ready – all additional stuff was there, like
documentation, training for users, etc

Now, I still like the four “dones”, but have a slightly different focus.
Since Stories are now well-defined bits of work, with well-defined
definitions of done, there is no longer the subjective third “done” for
them. The Product Owner no longer gets to decide if it is what is
needed, the story is defined to be done once the acceptance criteria are
verified. So there is not a hierarchy of things we do:

* Stories get “Done/Done”
* Features get “Done/Done/Done”, and we don’t know how many stories
this will take
* Products get “Done/Done/Done/Done”, and we don’t know which
features this will take, or how many stories it will take

This new way of looking at things shows us what is really going on.
Within the team’s work there is only tactical agility, where the team is
being agile in figuring out how to meet its story’s acceptance criteria.
There is low-level strategic agility where the PO is deciding which
stories to deliver for each feature in order to provide the value (for
that feature) that is needed. And there is high-level agility where the
PO is deciding what is the “releasable feature set” necessary to
actually be able to put this thing into production. Three different
levels of agility, three different sets of stakeholders, three different
levels of abstraction and questions to ask.

Dan Rawsthorne
dan@danube.com