Often when I read blog posts or articles about agile, they are talking about advanced concepts or solving funky problems that happen when you're in the depths of running an agile team.
The alternative are Masters of whatever flavour of agile is in at the moment. They are saying you start by following these exact rules that will save your whole team. I call bullshit on all of them.
In a previous post, I spoke about how there is no point is applying an agile band-aid if you don't work out where you are first and then add rigour to your current processes.
Once you do work out what practices your team is using and identify them and apply rigour, it is time to start putting in place some entry and exit criteria to initiate work and define success. I consider it drawing two lines in the sand that represent where we start and where we finish.
I always start with multiple Definitions of Done that apply to sprint tasks/stories, the entire sprint/iteration and the project.
This gives the whole team an idea of what it means to have completed a task and signed it off. That doesn't mean you comply with full continuous deployment and produce production releases at the end of each sprint (although we all dream of such a utopia) but it does mean that you have an end state that is achievable and universally understood. Working software is of course, part of this end goal.
It is important that this is understood before you even start the project so get this in place and get buy-in before you seriously put in any delivery effort.
Definition of Done for a User Story
I often treat the definition of done for a user story as the exit criteria for the swim lanes on a Kanban board. This defines when a user story that fits in a sprint is considered complete:
- Business analysis is complete [Owner: Business Analyst][Swim lane: In Analysis];
- Technical analysis is complete [Owner: Technical Lead][Swim lane: Ready for Dev];
- Estimation of effort [Owner: Entire delivery team][Swim lane: Ready for Dev];
- Implementation of the user story is complete [Owner: Developer][Swim lane: In Dev];
- Implementation of unit and integration tests [Owner: Developer][Swim lane: In Dev];
- Integration with all other sprint stories [Owner: Developer via Continuous Integration][Swim lane: In Dev];
- Automated packaging [ Owner: Developer][Swim lane: In Dev];
- Automated or manual deployment [Owner: Developer and Tester][Swim lane: Ready for Test];
- Full functional testing in a partially integrated environment where mocks are allowed [Owner: Tester][Swim lane: In Test];
- Sign-off of user story functionality, confirming implementation reconciles to requirements [Owner: Tester][Swim lane: Ready for Sign-Off]; and
- Sign-off from product owner that the user story has been delivered [Owner: Product Owner][Swim lane: Signed Off]
Definition of Done for a Sprint
A sprint is considered done when:
- Sprint planning was run and included the whole team;
- All user stories are signed-off by business;
- All user stories have been fully integrated with the current working software;
- Automated test coverage meets the agreed team standard;
- A retrospective has been run and actions owned or implemented by owners;
- Backlog has been groomed for future sprints;
- A deployable package has been prepared and versioned for release to an acceptance environment (that may be production); and
- Actual versus Estimated Velocity has been compared for future planning.
Definition of Done for a Project
This is a much tougher one. It depends on the situation you are in and the environment. Often we aim for working software and successfully full requirements reconciliation. There are many other things though that make this list. It is one that must be agreed to prior to delivering the project.
The important thing about any definition of done is that you must know up front what the goal posts are defined to be and not move them. Yes, you can change the way you play the game but you still know what it means to be finished.
Don't start until you know what it means to finish.
