Everyone wants to finish the application development project he or she is working on. It’s a big deal to complete something. It makes you feel good. You get to cross something off a list or feel the satisfaction of seeing software you worked on make someone’s life better.
Sometimes there’s confusion about what it means to be “done.” Does being “done” mean I’m done? Or that the team’s done? Or that the date we said we’d be done has arrived? Or that the software is finally out the door? Confusion on what it means to be done is a dangerous thing.
Nothing is worse than someone saying they finished something — and sincerely believing they had — to later find out that you both had a different impression of what it meant to be finished. When it happens, you have to deal with both the work, and rework, required to get the item completed and the potential lost of trust on future work.
On my current team, we talk a lot about being done. It’s a big deal. We’ve even developed some bullets around what it means to be done with critical tasks.
During a sprint, a story is “done” when it has been:
- unit tested;
- peer reviewed;
- all alerts have been logged;
- feature tested;
- any defects have been fixed;
- and the product owner accepts the story at sprint review.
A sprint is “done” when:
- all the sprint goals are met;
- all the stories have been accepted by the product owners;
- the team has performed their retrospective;
- and all the work for that sprint has been scheduled and moved to the appropriate release.
Outside of a sprint, a release is “done” when:
- all stories have been merged in;
- all defect fixes have been merged in;
- the merge has been peer reviewed;
- all outstanding test charters for the release have been executed;
- all final regression testing is completed;
- any user acceptance testing is completed;
- all the configuration management work is completed;
- all the configuration management work has been peer reviewed;
- and the release is deployed to production.
So how did our definitions for the word “done” become lists? Each bullet tells a small story about our team and the way we work. Many of the bullet points imply development practices (like peer reviews, unit testing, and exploratory testing) while others are milestones or events (like product owner acceptance or deployment). You get a feel for both our process, and our history when you look at what it means for us to be done.
Think about your own team. What does done mean for you? Is that a shared meaning? Ask around. If done means something different for you or your team, consider posting your meaning in a comment below.