Scrum/Done is done
What done means
In principle the definition of the word done in Scrum is very simple: An item is done when there is no work left.
That is the case when the functionality is ready to be shipped.
Depending on what the product owner specified in the product backlog when the sprint was planned, this can include a multitude of tasks:
- Concept
- Documentation
- Creation of test plans
- Coding
- Testing
- Briefing of internal users, upload to a website...
- etc. etc. etc.
Unless the product owner has set specific constraints (e.g. only developing a concept) it must always be assumed that all steps needed to roll the functionality out to the customer are part of the requirement.
Why is this difficult?
In a waterfall approach, teams are often only responsible for a part of the work, e.g. coding a solution. Documentation or testing may not be in their scope.
In contrast to this, the cross-functional nature of Scrum asks for full end-to-end responsibility of a cross-fuctional team.
However a perceived lack of competence and the desire to finish a lot of work rapidly often gives an incentive to fall back into the old pattern.
A critical product owner is therefore essential to keep the definition of done alive. Even though in the short term this makes things slower it provides clean, finished blocks of work that reduce complexity and increase quality in the long run.