Agile, People, Project Management, User Stories

#Done-but definition

During the last project kick-off workshop we discussed the definition of done. It was a very standard discussion to confirm that everyone had the same concept of what done was. As usual, it was an enlightening discussion as most people had some subtly different ideas of what done was. Eventually we agreed that done was the following definition.

“Done is either in production or in a such a state that if the sponsor asked for the functionality to be put in production, it could be done in a routine manner without any scrambling to complete outstanding tasks. The main activity would just be to schedule the actual deployment activities.”

During this discussion we talked about the difference between done and done-but. (Tip of the chapeau to Scrum-But)

We discussed that done is not:

  • Done – but I need to have the testers test it.
  • Done – but I need to write the help routines
  • Done – but I need to write the logging and auditing functionality
  • Done – but I need to write the exception handling
  • Done – but I need to complete writing the automated tests
  • Done – but I need to complete the documentation
  • Done – but I need to complete french version of the screen/report
  • Done – but I need to create and test the deployment procedure
  • Done – but I need to schedule and conduct a code review
  • Done – but I need to fix a couple of minor outstanding defects

We also agreed that done is not the status of an individual’s work on the story, but of story itself.

Great discussion and everyone now shared the same definition of done. This discussion also highlighted the fact that different people had different concepts of what the estimate contained. (Whether it was just development or development/testing or development/testing/analysis) But that is a topic for another post. Perhaps we should make it a point to always agree on a definition of Done and Do? 🙂

  • Done – Definition of what it means to be Done.
  • Do – Definition of all the things we need estimate and Do to be Done.

In the immortal words of Yoda: ‘Done or not done, there is no done-but’

About Terry Bunio

Terry Bunio has worked for Protegra for 14+ years because of the professionalism, people, and culture. Terry started as a software developer and found his technical calling in Data Architecture. Terry has helped to create Enterprise Operational Data Stores and Data Warehouses for the Financial and Insurance industries. Along the way Terry discovered that he enjoys helping to build teams, grow client trust and encourage individual career growth, completing project deliverables, and helping to guide solutions. It seems that some people like to call that Project Management. As a practical Data Modeller and Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical and real world approaches for both Data Modelling and Agile. Terry considers himself a born again agilist as Agile implemented according to the Lean Principles has made him once again enjoy Software Development and believe in what can be accomplished. Terry is a fan of Agile implemented according to the Lean Principles, the Green Bay Packers, Winnipeg Jets, Operational Data Stores, 4th Normal Form, and asking why


No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: