Open Space Notes: What is Done

Topic

This open space session explored the term done. What is done, especially for organizations with internal clients, where internal deployment is often difficult/delayed?

Discussion

Done is hard

·         Morale issue of not getting “done” if it includes things you can’t control

·         Deployment is hard for a variety of reasons

Possible definitions of done
  • In the deployment group’s hands
  • Generating P&L (for a company like a trading firm which gets immediate feedback
  • PO agrees it’s done (e.g. he/she has gone through a demo or tested it in UAT)
Deployment ticket is a problem
  • Queuing
  • Different priorities with other teams

Question: Can you make the deployment/downstream people part of the team?

Answer: Usually not because they are part of a necessarily-centralized area of the organization

Alternative: Invite them as guests to the sprint planning (or even sooner) to ensure “as little delay as possible”

Good idea: Have a staging area so that deployment is quicker, more reliable, “just a button-push”

Quality 

QA in the same sprint: does QA get crunched at the end?

Automated button-pushing testing is brittle.

Risk-based testing (see writing by Rex Black) may be valuable.

Thoughts on Done 

First and foremost: write down “what is done” and place it visibly.

Ritual to declare done: “Ring a gong”

Does “done” vary by scope/size, and does one size not fit all? Left unanswered.

Tags:

Visibility: Everyone