A Product Backlog item described as done varies a lot per Scrum team, so it does not necessarily mean the same thing for your team as it does for another team, even if the other team is within your company. The most important thing about “Done” is that everyone must understand what “Done” means. All Scrum teams should have a clear Definition of Done (DoD) that they can use to decide whether work on a story really is complete or not. This way it’s transparent and clear what exactly is expected of everything the team delivers, and it also ensures quality fit for the purpose of the product and the organization.
A typical DoD in the software world could be something like:
- the code is well written and follows our standards
- the code has been reviewed or pair-programmed
- it has been tested with 100% test automation at all appropriate test levels
- it has been integrated and documented
Over time, as teams mature, it is expected that their DoD will improve and be more stringent so that the quality delivered will have even higher quality. Adding to the example DoD above, the team could maybe add “Deployed to production”. This extra criteria of being deployed to production is not an easy task for a lot of teams, but speed is important and Continuous Delivery is definitively a competitive edge for a lot of organizations nowadays.
According to Jeff Sutherland it’s proven through data analysis of a lot of Scrum teams through Openview Venture Partners, that teams that have a stringent definition of done that is also called “Done, done”, doubles their velocity. “Done, done” means the work has been code completed and is fully tested on feature level. It’s less stringent than the example given, but enough to drive velocity up significantly.
Code completed in Sutherlands case includes all bugfixes – which means that bugs found in a sprint should be fixed in that sprint. This is actually a question I have seen a lot lately, whether or not bugs found in a sprint should be fixed within that sprint or whether the bugs should be estimated and prioritized for later sprints. Of course bugs found in a sprint should be fixed within that sprint – given that you have a DoD which demands code being completed!
To sum up: A DoD is important for creating transparency, so that all team member know what is expected from their delivery. So having a DoD is a lot better than not having one at all. If you in addition have a DoD with the “Done, Done” criteria which means code is completed (with bugfixes) and the work has been fully tested on feature level – your velocity could double! And who doesn’t want that?