Kicking off a new project, setting the cadence and planning your agile artifacts, from the product backlog, the scrum swim-lanes i.e (Backlog | To Do | In Progress | Done), the one persistently ambiguous status is when a user story is considered done. Developers and teams define the user story’s Definition of Done (DoD) differently, so what exactly does the developer mean when she says its done?
Scrum-masters observing a user story being promoted from the in-progress column to the done column, might conclude different things from done, such as the story is done but…:
- It has some minor bugs that has to be fixed;
- It is done but the UI needs some polishing;
- It is done but not tested yet.
These ambivalences make planning a project with the right effort estimation, and velocity tracking tedious. The constitution of user story completion. This also relates to my previous article, on How to Deal with Technical Debt in a Startup, and whether carrying technical debt with your ticket constitutes completion of user story.
I’ve raised a lot of questions here, but in an agile team, the scrum-master, product owner and development team need to come to a consensus on the definition of Definition of Done, and this needs to be factored in from the sprint planning phase where the team votes on the story points that would be the effort to complete the user story.
Its up to you to come up with the processes, but the point is, you need to have that formalized. Whether its to include it passing unit testing and continuous testing, a rating system for working out level of technical debt that would be carried, whether you need a column for product owner acceptance, go through gitflow pull-request (code review) acceptance. Establish the acceptance for marking a story as done as a team, and you ensure greater clarity and consistency in your agile board.