September 20, 2019
When I hear that something is “almost done”, I get worried.
You see, almost done is not done. It is started or underway. It may even be not started but reported as almost done to pacify someone. But to be clear, it is not done.
Almost done is a state of hopefulness. It is somewhere between “not started” and “done”, and we would like to believe it is close to done. Yay, we think, we have made some progress and we are almost there.
Almost done represents optimism and hope. We are communicating to others that we are nearly there! Woohoo.
But that is misleading.
Similar to the % complete situation. When we are asked to guestimate what % complete we are, we often do it very poorly.
Unfortunately, almost done is rarely close to being done. Almost done might represent the 90% done we use to use for progress reporting. Anyone familiar with technology projects know that the first 90% of the work is the easiest portion. In fact, there is a rule about software development called the Ninety-ninety attributed to Tom Cargill:
The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.
Consider also these examples of almost done, where the work remaining at the end is some of the very hardest part:
Part of the reason for the optimistic view of almost done is due to the planning fallacy, the tendency to grossly underestimate the time required to complete a future task.
Another factor is the lack of MVP, or the desire to gold plate the development. Rarely are the initiatives in the backlog small features that can be easily finished. Greg McKeown, author of Essentialism, says to use early and small, vs. large and late.
I encounter almost done most frequently when I am working with teams that are transitioning from waterfall to agile ways of working. We will typically meet with them prior to training and sprinting to understand their work in progress and help convert that WIP to backlog items for the Scrum team to work on.
In most cases, every individual has a list of things that are in progress. Some have 5 or 6 items. And everyone says that their items are “almost done”. In fact, they will almost always tell me that they will get them done before the time they get training and begin sprinting.
Except that they never do.
And even in the case where they do tell me they got it done, it usually doesn’t represent “done” according to the team’s newly developed definition of done. Usually it just means that someone coded it, and maybe they tested it. Or maybe they didn’t test it – I have worked with clients whose developers never completed unit tests. Yes unfortunately in 2018, we still have developers who think that testing is optional.
So when we go to start the first sprint, the team fesses up that though the items are still “almost done”, they didn’t make as much progress as they had hoped. So the status of the item is still “almost done” and we need to include those items in the first sprint. Against my caution, they put many of those items into the first sprint because after all, they are almost done.
And then those same items don’t get done in the first sprint, for a variety of reasons. It seems that almost done is almost never very close to done.
You can and should avoid calling things “almost done”. Here are some specific steps you can take:
Daria Bagina does an excellent job of dissecting the reason for getting to done in this excellent video, Done or not Done, there is no ‘almost’. She also incorporates the updates from the 2020 Scrum Guide. Check it out here:
What are your thoughts about calling something “almost done”?