Increasing predictability by moving the definition of DONE

The definition of DONE for an agile project team is quite important as that determines which stories are actually completed and can be accounted for in velocity for the iteration.

A team usually starts by treating a product owner’s approval after a showcase/UAT of a story as DONE. Though this sounds simple, it can get dirty when environments are not available to showcase on, or when the product owner is not fully engaged with the team. In such a scenario it is very tempting to go down the path of having Dev Complete or Testing Complete as DONE and go on claiming velocity without fixing the root cause.

Velocity is a measure of predictability and by moving the definition of DONE to the left side of the story wall reduces a teams ability to predict how much work they can chew. A team should always strive towards moving this definition to the rightmost lane of the story wall.

Definition of DONE	What you cannot predict ?
Development Complete	Bugs in testing, Bugs in testing by a Product Owner, Deployment issues in production
Testing Complete	Bugs in testing by a Product Owner, Deployment issues in production
UAT Complete	Deployment issues in production
Deployed	Really DONE – Its in Production !

Maintaining a predictable velocity is important to plan a project better long term. As a project manager of an Agile project one should strive towards moving to a "DONE = Deployed to Production" state with each iteration.

A nice side effect which starts to emerge is a reduced waste such as manual deployment activities which can be automated when one starts to focus on moving stories to the rightmost end of the story wall before accounting them in velocity.