10:00 AM Time for your team´s stand-up meeting.
Everyone tells about the tickets that they closed yesterday and explain what they will work on today.

When the round comes to you and the Agile Coach / Project Manager mentions the ticket you are working on, you say:

I am almost done, I just need to apply some final touches but it should be simple and quick

Fast forward a couple of days or even more and you find yourself repeating that again and again.

Yeah, I am pretty sure I will be done today, had a couple of blockers yesterday but now I am really almost done!

Let's be honest. How many times did it happen to you ( or you see this happen in your team)?
How can a task that you said it was almost done, end up taking 1 or two more days ( if not an entire week)?

Not trying to be mean or bossy here. I found myself in this situation many times. The thing is

Why are we telling others and ourselves the almost done lie?

Fear of judgment

Are we afraid to admit in front of our colleagues and superiors that we have been slower than it was estimated?

Avoid conflicts

Are we trying to be accomodating and avoid stating that we all knew that it was not possible to deliver on time and the estimate ( that was forced onto the team by management) was wrong?

Imposter Syndrome

This goes together with the fear of judgment but has more to do with the inner fear of not being fully capable of managing the task and that if we say we are stuck or are struggling, others might think we are not the experts we pretend to be.

Pareto principle

Are we aware at all that we are way behind schedule because the hardest part / or simply the longest part has yet to come?

The Pareto principle, also known as the 80/20 rule tells us that 80% of the feature is implemented in just 20% of the time, the remaining 20% will account for 80% of the time. Evil is in the details: we might have quickly already built the form or the RestAPI but we still need all validation, proper error handling or CSS and that will take lots of time!

Dunning Krueger Effect

Are we aware at all of our skills, do we have a clear picture of the task to be achieved, of the unknowns that might be hidden, of the possible blockers, of the technical knowledge required to accomplish it, are we maybe really overestimating our abilities?

The trap of Perfectionism

Maybe we are just too perfectionists?

We were really close to being finished (almost done_), but then we decided to refactor that ugly piece of code using some design pattern, or abstract away all duplications, and now we are halfway through the refactoring and everything stopped working, (and of course we don't want / can´t stash all our beautiful changes and deliver the old version)

or maybe we just really don´t know what Done means.

The definition of DONE

What does Done mean for you, for your team, for your boss, for your client?
Are you done when you just formally accomplished the list of things in the ticket and you can finally move the ticket out of the In Progress column then go to smoke a cigarette or play kicker?

When can a task be considered done?

50 shades of done

Are there different levels of Doneness?

• sloppily done
• good-enough done
• done done
• WOW! done

Have you ever discussed this with your team members and agile coach?
What are the steps to accomplish the task?

• Implementing the feature
• Write unit tests
• Do some manual tests to find bugs in usage
• Prepare it for different environments
• Integration tests
• Deploy it

Maybe your team splits those into different tasks, or between different developers with different seniority?
Maybe you come from a team or company where nobody ever cared about unit testing and now you struggle in considering those as part of your task when in fact they are taken for granted during the delivery of a feature

Doing the right thing

It may also happen that you are done, but you did the wrong thing because you were afraid of asking questions or you proceeded on wrong assumptions.

Maybe what you were asked was a simple prototype to test out an idea, a future project. Or an MVP (Minimum Viable Product) - a polished, working, production-ready, tested version of a product but with very basic features.
But you are there, still implementing a restful API for all the data sources, or fighting with CSS for the alignment or style of that Send button. All things none would care of in this phase.

Maybe you obsess on unit testing coverage and got lost in mocking/stubbing every piece of code when some unit tests and more integration tests would have been easier, quicker and actually more beneficial.

Many people talking about 10X Developers reason only about tech skill and speed but forget that fundamental aspect of efficiency AND effectiveness.

Efficiency is doing things right; effectiveness is doing the right things.

There is no point in being fast and perfect if you end up delivering something no one asked.

Scope creep

Asking questions, understanding the requirement and the expectation is also important to redefine the scope of your task and improve your sprint planning and team estimates
Maybe the task should have been split into more tickets, more granular sub-tasks, and then the big picture and the small details would have been clearer and so the time needed to achieve the task more precise.
When goals are defined, it is less common that many other small changes in requirements will be asked on the way ( without adjustments of the estimate or delivery date)

Code-review bottlenecks

How many times did you think you were done, but then you got the ticket bounced back during code review because your code was full of typos, you didn't write unit tests, you forgot to add validation in the Form Inputs, or you forgot to consider env variables and too many dependencies are hardcoded?

Simply the fact that you moved the ticket to For Approval within the estimated time, does not mean that it was done and that you delivered on time and now it´s the fault of that annoying picky code-reviewer and you now need more time to be "done" with those adjustments. (see Definition of done above)

Bugs

I am not say everything you push should be bug-free, but if you were requested to implement a form, and if you forgot to add a basic validation for a required field and everything crashes, you cannot just say..:

well, but that is a bug! I just implemented the form, let's close the story/task ticket and open a bug ticket for it. ( unfortunately, I heard that...)

and you call this "done"?

So, as you saw, there are plenty of reasons why a task could not be considered completed or could not be completed within the assigned time.
Deliver on time is essential for your team and company success and it´s essential as a professional developer.

This means that we should never be vague and we must be aware of the goal and our progress. And if it happens that you find yourself behind schedule, if you realize you are not going to make it on time, don´t lie, don´t omit the truth mentioning "simple final touches or irrelevant hiccups".

It´s not about feeling guilty and stressing about it, it´s more about informing your team and your project manager so that maybe you can get more time or you can get some help.

Cover Picture: Cape Town Foreshore Freeway Bridge - construction started in 1970 and left uncompleted in 1977 - and still there (I saw that while driving during my vacation in South Africa last October and was quite stunned..)