From time to time, I get status updates from the technical team that a specific feature is "done." However, when I check it, it hasn't fully been tested or ux tested with common-sense.
How would you define done so that the technical team consistently delivers features that are truly ready for launch?
There is no single, universal done definition. It will vary much between teams, depending on the product they work on (e.g. off-the-shelf software versus hosted web app), organization they're a part of (e.g. startup versus corporation), teams themselves (e.g. cross-functional versus functional), process (e.g. rapid and flexible versus heavy and formalized), etc.
The key thing is to have definition of done which is commonly understood among the whole project team.
It means the team should exactly know what is expected from them so they know that whatever they deliver should stick to these rules.
Also it does make sense to build similar done definition on specific steps of the process, especially when team's done product it just a starting point for another team (e.g. development with code complete milestone which goes to acceptance testing).
If you look at it from a perspective you can say that you're done when you don't expect to do anything with the feature in future. However it would usually mean deployment is a part of the process. Then the only thing which can happen is unplanned, e.g. bug submitted which needs a fix.
The concept of "Conditions of Satisfaction" is one that I have applied at project level for many years, which requires all stakeholders to agree on what "done" looks like at project level. I have started to use a similar concept at task or deliverable level recently, using the same principles, but usually limiting the stakeholders to those who are interested in that specific deliverable.
For a software module, the "Conditions of Satisfaction" could be something like:
It doesn't take long to define these "Conditions of Satisfaction" - it could even be a checklist - but it leaves everyone completely clear as to what is expected. It also means that where more than one person is involved in achieving the "Conditions of Satisfaction", they share the responsibility of delivering against them. For example, a developer and a tester may be involved in satisfying the requirement for successful testing, and they have to work together to achieve that. Neither can achieve it in isolation.
Once all of the "Conditions of Satisfaction" have been achieved, the job is done.
That's part of defining the task at the beginning to me. I learned a long time ago that people often only see their part. It's done to a developer when it's written and they hand it off to the testing team. It's done to the testing team when they've tested it even if it fails.
My suggestion, be clear what you mean by done when the task is assigned.
This generally is different for every team as everyone's environment is different, so of course there is no one great answer. We generally let the team define done with the guidance that it should include everything required to get that feature "production ready". The theory being that at the end of any sprint you could go live with those features in production. In fact...if at all possible, you should, though there are many reasons why you may not be able to. Some things that are common on our lists of done criteria are...
Also, don't forget Product Owner/customer approval. And of course, this list is a living document, so if things continually cause problems, something should be added to the list to address that. In the same sense, some things may become second nature over time and can be removed from the list as it is no longer necessary to explicitly call them out.
On my projects, we jointly develop with the customer evaluation criteria for each deliverable and product material. These criteria are sort of decomposed requirements that explicitly detail tangible, verifiable elements of the product that can, to the degree possible, be objectively scored/evaluated. It serves two purposes: 1) it helps define the initial requirements to a lower level of specificity that helps remove ambiguity that often exists in initial statements of work, and 2) it defines finish.
In the QM process, there are QC checkpoints that strategically distributed throughout the development life cycle that enables the team to measure its progress against the evaluation criteria, with in some cases marking off some of the criterion during development versus at the end. The final QC checkpoint establishes that each criterion has been met, defects captured, and process checkpoints have been met. The final review of the evaluation criteria is not the opinion of one but rather the collective opinion of the team. This is established when it begins to appear that the benefit derived from continued development no longer exceeds the cost of doing so AND the risk of customer rejection has been mitigated to an acceptable level.
But, the final approval of calling a product complete occurs in the scope verification and validation process, which includes the customer's review of the product and final disposition of rejection or acceptance.
I like to define done by collaborating to create numerous precise, concise examples of the feature in action. Then automate the examples as automated tests.
The collaboration is done with "the three amigos," the product owner, one or more people who understand the technology (e.g. developers), and one or more people skilled at probing boundaries and detecting ambiguity (e.g. testers). The goal is for everyone to ask questions and pose scenarios to define the scope of the feature relatively comprehensively—what's in scope and what's out of scope. Collaborating helps to build a shared understanding.
As the group fleshes out its understanding of the feature, express that understanding with concise examples. This help to make the shared understanding concrete. I've had people tell me, "With these examples, I have a much better understanding of what we're all trying to accomplish. So instead of just working on a feature, now I actually care about it."
Automating the examples helps to make them more available and more visible to the whole team. And they become a marker of progress. Each time the system passes another test, that's a clear sign of progress, and it's progress that someone cares about.
There may be criteria that don't lend themselves well to concise examples and automation. So I also like to identify areas of risk or concern (again, collaboratively). Then, as soon as there is functionality to execute (even if it's not done yet), begin exploring the feature with exploratory test sessions.
