An Agile expert shares his thoughts on the importance of creating an attainable Definition of Done during Sprint planning, and the 90% syndrome among devs.
Getting to Done at the end of each iteration is an important principle in Agile. Here’s why.
One of the tenets of Scrum is the value of getting work done. At the start of a Sprint, the team selects some set of product backlog items and takes on the goal of completing them.
A good Scrum team realizes they are better off finishing 5 product backlog items than being halfway done with 10.
But why?
One reason to emphasize getting work to Done is that it shortens feedback cycles. When something is done, users can touch it and see it. And they can provide better feedback.
Teams should still seek feedback as early as possible from users, including while developing the functionality. But feedback is easier to provide, more informed, and more reliable when a bit of functionality is finished rather than half done.
A second reason to emphasize finishing features is because finished features can be sold; unfinished features cannot.
All projects represent an economic investment–time and money are invested in developing functionality.
An organization cannot begin regaining its investment by delivering partially developed features. A product with 10 half-done features can be thought of as inventory sitting on a warehouse floor. That inventory cannot be sold until each feature is complete.
In contrast, a product with 5 finished features is sellable. It can begin earning money back against the investment.
A third reason for emphasizing getting features all the way to Done is because progress is notoriously hard to estimate.
Suppose you ask a developer how far along he or she is. And the developer says “90% done.”
Great, you think, it’s almost done. A week later you return to speak with the same developer. You are now expecting the feature to be done–100% complete. But the developer again informs you that the feature is 90% done.
How can this be?
This leads to what is known as the 90% syndrome: Software projects are 90% done for 90% of their schedules.
In Agile, we avoid the 90% syndrome by making sure that at the end of each iteration, all work is either:
We’ re really good at knowing when we haven’ t started something. We’ re pretty good at knowing when we’ re done with something. We’ re horrible anywhere in between.
Have you experienced problems with teams being 90% done? How have you overcome these problems? Please share your thoughts in the comments below.
