& Continuous Learning

I recently presented on the topic of Definition of Done at our Monday Meetup. The purpose of the game was to help our teammates understand what “done” means. As a product owner, I hear a lot of keywords thrown around in the Agile Development process; Minimum Viable Product (MVP), Minimum Marketable Product (MMP), and Minimum Marketable Feature (MMF) just to name a few. As a development team, how do you really know when good is good enough or as I like to say “done”?

Since it was called Definition of Done, I started with the definition. The word done can be a verb, adjective, informal usage, past tense of do, or even an exclamation. After we all had a general understanding, we started the game.

Purpose of the game

The goal of the game was to help teams understand how to identify done, when good is good enough and who ultimately makes the decision. It was also to demonstrate that MVP doesn’t always equal “done.”

Setup

Teams have to build a house with a garden based on pointed story cards. Basic information is presented to the teams including:

• Basic requirements
• Stakeholder needs & wants
• Velocity per sprint

Each team nominated someone to play three roles:

• Product Owner: Help the team deliver value
• Key Stakeholder: Understand the entire scope of the project
• Team: Developers and quality assurance to deliver projects

All of the stakeholders were gathered and given additional instructions. During this time, the teams got a chance to look at the estimated house and garden story cards.

Game Play

The teams started organizing the story cards into sprints and prioritizing what could be done now and what could be done later. As a result, there were a lot of great questions and observations.

"Wait a minute that wasn’t told to me at the start; that changes everything."

“How do we know if we are done?”

“How many sprints do I have?”

“What area of the country are we building the house and garden? That might make a difference to how or what I build.”

Several teams had formal discussions to ensure the everyone on the team understood when they were “done”. They established a formal process to state when there were finished.

Two of the teams made sure to consult their stakeholder right away, while the other two teams started working before talking to their stakeholder. All of the teams ultimately delivered what the stakeholder requested. The teams each got there in different ways and in a different amount of time.

Lessons Learned

Once the teams completed determined their sprints, we took some time to revisit MMP, MMF, and MVP. Also, we talked through the different levels of done: story level, feature level, epic level etc.

Here are a few things that the teams learned:

1. The team needs to discuss roles and responsibilities.
2. How do you ultimately decide when the project is done?
3. It is ok for the team to determine that it is good enough or done for now.
4. The team and stakeholders may decide to add features later.

Overall the game was a success. Several teammates are now using this as an exercise within their own teams.