At Made Tech, we’re big into Agile methodologies, particularly Scrum. As part of these practices, we’re constantly analysing and evolving the way we work and trying to find ways to improve our software delivery practices.
One of the areas we focus on is how to ensure user stories are ‘done done’.
To us, ‘done done’ is about ensuring a feature is complete and ready for deployment to production. There shouldn’t be any further work required on the feature, except possibly the click of a button to deploy the code to the production infrastructure.
So, why is getting to ‘done done’ important to us?
The Scrum methodology is fundamentally about breaking large complex projects into smaller chunks of work, which are delivered incrementally. These increments need to be shippable, so they can be used by end-consumers and provide value back to our customers.
It’s therefore very important that when somebody says a user story is ‘done’, it’s truly complete and ready for launch. If it’s not, then you’ve got a story which is still a work in progress and it’s going to require additional time to complete. It’s not done.
Internally we’ve got a number of criteria that help us to decide whether a user story is ‘done done’, or not:
- Does it meet the customers requirements?
- Does it have a good level of code coverage?
- Is the test suite still green?
- Has it been cross-browser tested?
- Has it been performance optimised? Does it need to be?
- Has it been checked for security vulnerabilities?
- Does it adhere to our code style guides?
- Is the code considered clean and maintainable?
- Does the code need a peer review?
- Has it been deployed out to a production-like environment?
- Are we happy with this feature?
When an engineer considers a story ‘done done’ and the scrum team agree that the user story meets these criteria, we’ll consider it complete and the engineer can start working on another task, confident that the previous task is closed out.