Open Space Notes: What is Done
This open space session explored the term done. What is done, especially for organizations with
internal clients, where internal deployment is often difficult/delayed?
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
- 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”
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
Thoughts on Done
First and foremost: write down “what is done” and place
Ritual to declare done: “Ring a gong”
Does “done” vary by scope/size, and does one
size not fit all? Left unanswered.