In addition to my previous post about questions from the ‘more classical’ world regarding progress and the different methods of measuring progress, I’m now writing about another common and rather popular question: When is your product done?
To be able to answer this question, let’s first try to define what a product is.
Definition of Product
In our case, from a business perspective, a product is something that helps customers get their jobs done.
Every product is different. Some are developed for doing more jobs, some for getting a job done better. Others for new users or new jobs. But they all help customers in getting jobs done.
How the jobs are performed is analysed by the users and stakeholders. This leads to the creation of the vision and goals for the product.
Hypotheses
These goals and other assumptions about the product are just hypothetical and need to be tested as soon as possible. From a development perspective, a product can be considered a group of hypotheses which need to be tested in the real world. By studying the results of the tested hypotheses, we can pivot or persevere.
Software development is soaked in testing hypotheses. By quickly going through the Build-Test-Learn (The Lean Startup – Eric Ries) loop, you’re able to objectively evaluate your assumptions. The outcome of these tests, gives you the opportunity to make an educated guess on how best to proceed; pivot or persevere. These tests can be considered as small projects on their own, with their own agreement of the completion marker.
Done Product
So, when is the entire product done? When do we waive the checkered flag?
To be able to answer this question, it’s best to formulate an agreement with your stakeholders regarding the specific completion moment of the involved hypotheses; a marker that indicates that the product is done. In fact, if the agreement is made, this question does not have to be asked at all. During the iterations where you test your hypotheses, you are constantly measuring and evaluating the outcomes and when you reach the agreed marker, you are basically done for that specific hypothesis. A lot of things can happen, like market shift, goals changes, etc. So the agreement is also subject to change. Which is okay, that’s why we are working Agile. In the case of a changing goal, there is no need for panic. You just keep measuring and evaluating with your stakeholders and make an educated decision about whether to pivot or persevere.
Like the example above, the agreement about the completion can be about the goals, but these can vary. For example budget, lead time, date, availability of all kinds, even scope (MVP), etc. As long as you make a clear agreement, it is very easy to decide when your product is done.
Discard
It could happen that a product gets thrown away. I’ve been there. It feels a bit scary, strange and unsatisfactory. We are used to aiming for success and discarding a product doesn’t fit this paradigm. But when you consider it from a different angle, discarding a product could very well be a good thing. That gives you time for testing new hypotheses, using the lessons you’ve obtained in the previous product and you don’t waste money in a product that doesn’t get the job done. Discarding is a pivot decision.
Finally
Like I wrote, a product has a goal or multiple goals and is the outcome of a group of tested hypotheses.
The hypotheses are assumptions about the customer jobs. Your Product Backlog exists for development purposes and its items (PBI’s) reflect the customer jobs. The PBI’s can be measured by using the Definition of Done within Scrum. So, there you have three levels of Done.
- PBI’s; using the Definition of Done (Scrum)
- Hypotheses; testing assumptions in real world
- Product; reaching goals
Different types of Done
To answer the question (When is your product done?) you need to create the answer before you start working on it.
When you’ve achieved the intended goals and all hypotheses are tested, decisions are made and there is no need for new ones, you simply stop developing the product.
You waive the checkered flag :).
But, you keep measuring and watching the market closely. If necessary, you start working on your product again.
The new Scrum Guide (nov 2020) is now also referring to the Product Goal.
