When is something good enough?

A technical work item can come from many different sources within an organization. Maybe it originated from a customer support ticket or a stakeholder, or the strategic road map assembled by the product team. In each of these scenarios, the work item gets placed on the backlog, prioritized then executed by you, the individual contributor. Now depending on the organization, there may be a TON of acceptance criteria that have to be implemented to call the work item completed. Other organizations have very little to no acceptance criteria within the work item. In either scenario, how do you, the individual contributor who will be executing on the work item, know when to call the work item complete?

Let's face it, this career path is not always the easiest. No matter how many acceptance criteria we have to work with there are still gaps. Not every permutation of functionality has been completely thought through before it is time to begin implementation. Not every solution consideration has been put on the table for review and selection of the "best" option. Working in such a manner would kill an organization. Too much time would be spent on solving 1 implementation, while the competition is out there delivering 5 times faster. This is the start of over-analysis.

What if we flip the coin and put no acceptance criteria on a work item? Does that allow us to move faster and outpace our competition? Perhaps it would, but other issues potentially arise. The team and implementor may not understand what is needed. Resulting in a product that contains features that are not cohesive. A product that is functionally there, but not presented in a way that customers understand how to use it. So the product is rich with features and functionality that do not complement each other or are difficult to even comprehend. This results in the same effect as over-analysis, killing the organization.

Spending hours on the acceptance criteria or spending no time on the acceptance criteria for a work item yields the same result? How can this be true? What can be done to get something good enough for the customer? Communicating the essence of the work to the implementor is what needs to be done. In this state, a title and short description of the value to the user is enough to get started with implementation. As the implementor solves the major pieces of the work item, there will be gaps in their knowledge and they won't know what the best decision is. That is 100% normal. Before, jumping into the rabbit hole of solving this issue, the implementor should have a conversation with the team to resolve this impediment. If the team is unable to answer the question or does not feel comfortable, escalate the issue to someone who can. The implementor should do nothing else except seek to resolve the open questions.

As more and more of the functionality exists, it is at the judgment of the implementor to review the functionality with the appropriate party. In some cases, this may just be a quick screen share. In others, it may be something completely different. The goal is to get immediate feedback on the work. The quicker the feedback, the sooner the implementor can move on to the next work item. It is important that the implementor not put any more time and effort into this work item than necessary. A complete refactoring is out of the question at this point. One has to keep in mind that customers do not pay for how easy it is to add new features. They care about the here and now. It works, it is not a perfect code or perfect presentation, that is perfectly fine. The goal is delivery, with a modest sense of maintainability, and continue to the next.