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.

No fluff, just releases into production every 2 weeks

My current project is a small Ruby on Rails application which is part of a larger web portal. The fun part is that we are releasing new features into production every 2 weeks. Each new feature adds a lot of business value to end users as well as the business stakeholders.

The business we cater to is evolving at a fast pace, and as an IT team, this quicker delivery service provides them a  lot of flexibility. The dynamic nature of business means that we never have requirements which are frozen, even for a period of 2 weeks. This also means that the IT team needs to respond to the changing requirements very quickly.

An important practice that has helped us, is to deploy into an exact production replica UAT environment 3-4 times a day so that the latest application is always available for the business to provide feedback. The business is exactly in the same situation as Jeff Patton describes here http://www.agileproductdesign.com/blog/dont_know_what_i_want.html by not knowing exactly what they want, and the rapid feedback cycle on the latest developed application allows us to build the feature right for them.

Most of our deployment scripts to UAT and Production are automated to an extent that it is a one click deployment to production. Not only does it make deployment simple, but also rollback simpler in case of an unexpected error.

We are still managing without creating a production branch. Having a production quality application in the UAT environment almost everyday helps us in applying an urgent bug fix if required and deploying it to production the very next day. Having a good version control like Mercurial is useful to keep half done stories outside the production build in such cases.

Lastly we do not spend time doing estimation on stories. We tend to keep the backlog to a minimum and try to move almost all the stories in progress to production every 2 weeks.