done/done/done/done
A few years (about 6-7, I think) I introduced the team “done/done/done”
into agility in order to describe what “done” meant in an agile setting.
It is now pretty established the “done” is a HUGE concept in scrum, but
at the time we were just figuring it out. My thinking at the time was
that a Story was “done” when it was “Done/Done/Done”, where the three
“dones” meant (coded/verified/validated). That is:
* 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
