Definition of Done

I created the following document in my work as an engineering and product leader.

We are convinced that we can deliver high-quality applications and services at an overall faster rate and with much happier customers if we do things “right” the first time, rather than rush through our work just to get a feature out. We take our time to work with high-quality, craftsmanship and low tech debt. We’re convinced that if we do this, we will spend the majority of our time working on improvements and features as opposed to fixing bugs, troubleshooting support issues and reworking tech debt. We're also convinced this can lead to a sustainable pace. This leads to our definition of Done.

What does Done mean for Product Development? When is an item Done? This is our definition and how we do that. But first, the How.

Our Practices, the How

Professionalism

We act with a high degree of professionalism. We adhere to the ACM Code of Ethics and Professional Conduct.

Agile

We're not enthusiastic about the dogma and ceremony that have become part of many agile approaches, but we are still big fans of the original Agile Manifesto, especially the 12 Principles behind the Agile Manifesto. We practice Agile software development in accordance with those principles.

Clean, Obvious Code

We write code that is easy to read, easy to understand, easy to test and easy to extend and modify. The naming and organization of our code make its purpose and function obvious to the reader. We avoid using tricks or syntax shortcuts that make code harder to read and understand.

Operations and Security Excellence

We strive to meet or exceed the our Operations and Security Baseline. We invest in improving our infrastructure, security and operations. We constantly monitor our production applications and ensure they are reliable, secure and performant. Our product is NOT just our code. Our product is our customer’s experience using our running services and applications.

Thin Vertical Slices

We believe that small is better. We understand the value of delivering vertical slices. We separate our work into thin vertical slices and take each slice all the way to Done. Our goal is to create slices that can be completed in a day or less.

GitHub Flow

We follow the GitHub Flow process. We create small, short-lived branches for our work. When ready we submit a pull request from our branch to main. At least one other engineer reviews and approves the branch. When approved and validated, the branch is merged and deleted. Merging kicks off automated processes that ultimately may automatically deploy the changes to production if all tests pass.

Zero-Bugs

We practice Zero-Bug Software Development. In short, we fix ALL known bugs and support issues BEFORE we work on new improvements or features. It doesn’t matter who created the bug or who owns the area. We all share this responsibility.

Limited Tech Debt

We strive to keep our tech debt near zero on an ongoing basis. However, we are pragmatic and use good judgment to balance quality with speed. We are also willing to take iterative steps towards an ideal architecture and implementation.

AND

We believe in AND, not OR. We can work on new features AND fix bugs AND reduce tech debt on an ongoing basis by correctly prioritizing the right things.

Cows, Not Puppies

We build Cows that can be put out to pasture and ignored. We avoid creating puppies that cause all kinds of problems and require constant attention.

Issue Tracking

We track our work! We have an issue open for EVERYTHING that we work on and we keep the issue status up-to-date as we work on it. We move it to In Progress when we start. And move it to Done when we’re Done.

Minimum Requirements

These are the minimum requirements we meet before we mark an item Done.

Ideals

LIZARD CRAMPS is an acronym for the 12 ideals we work towards in our product work. Before marking something done, we consider all of the LIZARD CRAMPS ideals.

Localizable

We make our products internationally capable from the start, providing the ability for customers to read in other languages and enter and view data such as dates, currency, and addresses in the format that is familiar to them.

Interoperable

Robust APIs make it easy for our systems to exchange data and interact with external systems.

Zero-Bug

When we become aware of the following situation in our products, we finish work in progress then fix it before working on pending improvements or features.

The system is not behaving as specified, but consumers are able to receive the value they’re entitled to; or the rate of money / time wasted resulting from the issue is acceptable for the short-term. This makes our level of unplanned work more predictable, improves the overall quality of the product, and boosts morale.

Accessible

Our products are WCAG 2.1 AA compliant. We understand our customer’s legal obligations to provide accessible systems.

Responsive

Where it is possible to support the best user experience, we design screens for mobile first. In some cases, multiple views / screens to edit the same data may be required to achieve the best experience. And, in some cases, it may not be a priority to make a particular screen mobile-ready.

Designed

We have a strong focus on using our product framework to design the right features to solve a stated problem. This involves working closely with designers in the process, conducting user testing where applicable, validating a solution after it is released, and following standardized design processes across all products.

Current

To stay secure, avoid surprises, and achieve predictable velocity, we consume the latest versions of libraries and dependencies as soon as we can validate th

Reliable

Our software is available: we commit to 99.9% uptime. The behavior of our products is predictable: we use feature flags to allow our customers to consume improvements and new features at their own pace, and we thoroughly validate and communicate changes.

Automated

We use the 12-factor methodology for building SaaS application, and we automate, automate, automate: quality assurance (acceptance testing, performance testing, security testing, "ility" testing, etc.), licensing, production of documentation and release notes, deployment, security, and monitoring. We are able to be constantly confident of the service we are providing to our customers.

Maintainable

We write clean, obvious, easy to maintain code. We do via many practices including Automated, Zero-Bug, and the following.

Modular: We use a Self-Contained Systems architecture, separating code along reasonable lines of utility and accountability, such as workflow, protocols, curriculum management, continuity planning, and procurement.

Shared: We constantly look for opportunities to share and reuse code. This leads to efficiencies and an enhanced end user experience.

Performant

We understand the snowball effect of sluggish software on the satisfaction and productivity of our end-user community and ultimately the bottom line of our customers. We have established clear performance metrics for different types of functionality and measure our adherence to those metrics.

Secure

The security of our customers data is our utmost priority. We understand Service Organization Controls (SOC), laws such as FERPA and HIPAA, industry standards such as PCIDSS, and the higher education data classification system. We leverage services such as AWS that are certified compliant with our customers desired security standards. We are experts on securing web applications and use the OWASP risk rating methodology. We scan our code as well as the libraries that it depends on for vulnerabilities. We scan our products for vulnerabilities. And we address those vulnerabilities as quickly as possible. We are transparent with our customers about potential exposure and do everything in our power to avoid, mitigate or remedy exposures.