Defining the Definition of Done as a Product Owner
Updated: Mar 4
How often do you work on a project and not know whether or not it’s finished? What kind of tweaks can you make? What could be added to make a feature better? As the product owner on Eira: Echoes of Adventure, part of my job is to help establish what the definition of done is. “The definition of done, what is that”, you might be asking. In scrum, the definition of done is prescribed by the company and requirements can be added by the scrum team. The definition of done is to help establish a set of criteria that stories and features must meet before they can be marked as complete.
In the recent few sprints, there has been a lack of criteria made available to the team about what must be completed for a story. We would typically sit in sprint closing and not be completely sure if a story or feature was completed. There were two main components that created this confusion; firstly, we hadn’t described what it meant for a story to be complete, secondly, I made a mistake when creating the master backlog and wrote some features as regular stories. There were some stories (which were actually features) that we were working on that should’ve been broken down into multiple stories. When the feature is broken down, we could finish the story by the end of the sprint. For example, we found that “creating a level” was too broad of a story because there were many components that went into it. We broke that feature down into multiple stories like; “blocking out the level”, “implementing art”, and “staging lighting”. These weren’t the actual names of the stories, but I think you get the idea of what we were going after. But this still doesn’t answer what we did about the definition of done….
To make sure the team has an understanding of the definition of done, we went over a set of criteria in a meeting…
For a story or feature to be marked as complete…
- All relevant work must be implemented in build
- All relevant tasks must be marked as complete
- All relevant tasks must be approved by your lead
- All relevant stories must be approved by the product owner
In addition to the criteria we set up for stories, each story also has its own conditions of satisfaction. In the master backlog, when a story is created there is a column for conditions of satisfaction. Conditions will briefly describe what the story needs to accomplish and sometimes be more specific about dependencies with other systems. This conditions of satisfaction helps team members understand what is expected from them for the tasks they have.
The end of our fifth sprint will be the first sprint to have conditions of satisfaction set up for every task. My prediction is we may have to outline conditions more detailed for some members and reference documentation for them as well. I am also hoping that in general more stories will be marked as complete and we will have better results from our planning. Since this is a new thing for our team, you will have to stick around to hear how it went in another few weeks!