What does Done Mean?

What does Done mean?

Yesterday in the parking lot two related questions were asked and I offered to give an answer that would relate them. The questions were What does “Done” mean? and What constitutes potentially shippable code?

First, let me address the easy one: What does “Done” mean?

Well, the literalist in me wants to point out that “done” is merely the past participle of the verb to do, and as such indicates the completed action of the active verb. Dictionary.com defines “done” nicely as accomplished. When we consider “done” in relation to our development efforts, there is really only one way to define it: No milestone has been accomplished until the product owner acknowledges it as such.

Since the Product Owner is responsible for the creation of any particular story, only they can determine whether or not their intent has been accomplished. Procedurally, we drive to eliminate a bulk of the subjectivity by defining acceptance criteria while we write the initial story. This approach is consistent with TDDevelopment as it concretely defines the finish line for the team before they start.

Potentially Shippable refers to a state of the system from whence it is actually presentable for General Availability (GA). Clearly there are a bunch of details that need to be completed in order to move stories from “done” as accepted by product owners to GA and accessible to external customers. Examples of these details are the compilation of printer ready pdfs from completed user documents – clearly this needs to be done once all the documentation updates are “done”, but before the product can be considered shippable.

Often, teams utilize one or more hardening sprints during which these final details are completed and while system level performance testing and training can be undertaken. Additionally, during these hardening sprints, the teams are able to address lingering issues such as defects that have not been completed or even take on a couple additional stories, as long as all changes are staged prior to being integrated into the release candidate.

So, granting these definitions, teams frequently have difficulty in applying the abstracts concretely to their projects. Specifically, what are we talking about?

1) High level stories are written by the PMs. These are narratives that walk the reader through a scenario that is obviously testable: when a scenario is run, a predetermine result can be perceived. Depending upon the complexity of this story it may be broken down into more manageable chunks, each with their own results based acceptance criteria. When the work is verified, it is verified at the lowest level – typically a task of 1-3 days duration. When the work is validated, it is validated at the highest level – typically the larger story’s scenario. The theory here is that if all the low level pieces are verified and the story can be validated at the abstract level, then by induction all is complete.

2) Similarly if we are going to verify at the lowest level, we must ensure that we have all the component packages identified at the task level so that the work it self can be inclusive. If we need end-user documentation for a particular high-level story, then there should be stories and tasks associated that cover these activities. If we have an end-user, we need to incorporate useability stories and tasks. Ideally, a check-list should be created to help the teams ensure they have included tasks which cover the entire spectrum of activities that are necessary. There is a caveat however; the spectrum of activities must correspond directly with the acceptance criteria put forward by the PM when the story was initially written. If they don’t feel a certain aspect needs to be incorporate, then don’t. On the other hand, if the team really feels it does, they should initiate a dialog with PM to determine whether they have discovered an omission, purposeful or not.

Thus, Done means the stories are verified by QA against their acceptance criteria and there are no lapses. Potentially Shippable means that all high level stories are validated by the PMs and demonstrable to the organization as complete.