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 is passionate about his work as the Manager of the Project Management Office at the University of Manitoba. Terry oversees the governance on Information Technology projects to make sure the most important projects are being worked on in a consistent and effective way. Terry also provides leadership on the customized Project Methodology that is followed. The Project Methodology is a equal mix of Prince2, Agile, Traditional, and Business Value. Terry strives to bring Brutal Visibility, Eliminating Information islands, Right Sizing Documentation, Promoting Collaboration and Role-Based Non-Consensus, and short Feedback Loops to Minimize Inventory to the Agile Project Management Office. As a fan of pragmatic Agile, Terry always tries to determine if we can deliver value as soon as possible through iterations. As a practical Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical and real world approaches for both Traditional and Agile approaches. Terry is a fan of AWE (Agile With Estimates), the Green Bay Packers, Winnipeg Jets, and asking why?

Discussion

No comments yet.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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: