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.
