These days, it seems like everybody is all about doing things agile. That’s largely due to agile’s ability to adapt to change and incorporate customer feedback, both of which are essential in today’s world where technology is constantly evolving, and swathes of information are just a few clicks away—including public customer reviews.

Responding and incorporating customer feedback into products and processes requires self-organizing teams that are constantly tweaking what they do to be more efficient,  where they can change regularly to meet new needs that pop up daily. When it comes to project planning, this fluctuating environment can make things tricky: hard deadlines and a predetermined set of deliverables are nearly nonexistent.

So if a foundation of agile is working fast and changing rapidly and often, while continuing to iterate on the project, what’s the definition of done in agile? When can you truly say that you’re finished? That’s an interesting question. But first, let’s get some more background on agile and its methods.

How Work is Done in Agile

Simply put, agile in project management is taking an iterative approach to planning and guiding project processes, where change is encouraged. It’s on the other end of the spectrum from traditional project management methodologies, such as waterfall, with their strict structures.

Agile is a process that is set up for small teams to work in short “sprints,” which helps them respond quickly to the unpredictability of change in a project. Teams meet regularly before sprints and after to adjust how they work to take into consideration the changes that have occurred in the project.

Related: Agile Sprint Planning Template

It’s through this framework that organizations create the product that the customer wants and not one that has been designed in a vacuum, unaware of needs and marketplace currents. Teams can figure out better routes to develop the right product amid the project because they’re able to pivot as needed. This makes organizations more competitive, but it also makes it hard to mark something as done when there’s seemingly an endless task list of feature updates and other fixes.

The Definition of Done in Agile

Now that we know the context, let’s address the initial question about how to determine when you’re done in agile. One answer is that you’re done when you’ve finished the sprint, which is a short duration of work during the project, often a day or a few days but no longer than a month. At that point, the team meets and reflects on the work done, what’s changed and the best course of action going forward. There is a plan, but that plan is adjusted to reflect the realities of doing the work.

Finishing Iterations

Ideally, after each iteration, the project should be done. But that’s not the case often. Things come up that must be addressed and make the project pivot to respond quickly to those alterations. Therefore, a release after every sprint is not advisable. But it is important that each feature is completed in the sprint in order to track the progress of the project.

Therefore, being done means making sure that each feature is fully developed, tested, styled and accepted by the product owner. Only then is it done. And there are a lot of “done’s” in agile. But if there are doubts about these activities, then that sprint isn’t done and certainly should not be shipped.

Each feature relies on another feature’s completion before the product is really done and shippable. That would be the overall done. However, each sprint has a feature that should be done by its conclusion. By done, that means that feature by itself can ship if it had to ship by itself.

This whole process can be expedited when your team operates using agile software. Agile software lets teams collaborate when they need to, without losing focus on their own work, ensuring that things really do get “done.” Watch the short video below to see how agile software can help your team.

Differs by Team

But each team has its own definition of done, which is just another way of saying that the criteria across all user stories have been accepted. But whatever that definition is, it drives the quality of the work and assesses when a user story is complete.

In terms of software development, done is when something is coded to standards, reviewed, implemented, tested, integrated and documented. In a service context, that means every task of the user story is complete and the product owner reviewed it and it has met their expectations.

Being done in agile means that the team is aware of what is expected of them to deliver and they have delivered that. Done is a means of transparency. It makes sure that the quality of the work fits the purpose of the product and the organization.

Can the Definition of Done Vary?

Agile is the overriding methodology and the agile process can be executed with a variety of frameworks. Some of those are Scrum, Extreme Programming, Adaptive System Development, DSDM, Feature Driven Development, Kanban, Crystal and others.

These processes are ways to work within an agile framework, but they have different approaches and features that can apply best to one type of project or another. That’s up to you to decide which of them is the best when working on your project. That doesn’t mean you have to choose only one. A combination of some or many might best work with the demands of your project. This flexibility of agile and its process is one of the driving factors in its wide and growing appeal. Although they are different processes within agile, they all adhere to the same definition of done.

The Principles are Constant

Agile has been around since 2001 when a small group created the Agile Manifesto in response to traditional approaches to managing software development. The manifesto outlined basic ideas that are present in each agile framework. The four main thrusts of the manifesto are:

1. Focus on individuals and interactions rather than processes and tools
2. Creating software that works is more important than comprehensive documentation
3. Collaborating with customers is more important than contract negotiation
4. Process follows change instead of a plan

There are also 12 principles of agile software development. These principles feed into our understanding of when a task or project is truly done:

1. Customer satisfaction is delivered by constantly delivering valuable software
2. Change in requirements are always accepted, regardless of how early or late in the project
3. Software that works is delivered in a shorter timescale
4. Developers and business professionals must work together daily throughout the project
5. Face-to-face communication is best
6. Motivated teams come from creating a culture of appreciation, trust and empowerment
7. Progress is measured by working software
8. Agile process promotes sustainable development
9. Agility is supported by attention to quality in technical development and design
10. Agile management is based on simplicity
11. The best architecture, requirements and design come from self-organized teams
12. Teams are more effective when they reflect and adapt

Agile Outside of Software Development

While agile was birthed in the world of software development, recently it has branched out into the wider business world. The ideas of agile, lean and organizational learning have moved outside the small circle of software development, with businesses of all sorts using stand-up meetings prioritization and visual management.

Agile was never intended simply as a tool of IT project management. The techniques of agile can change the management process in other enterprise projects. Using agile thinking to change management projects is an example that works very well.

Some aspects of agile that can be used in enterprise projects include backlogs, which are the functions and features that will be part of the final delivered project. Spring or short projects within the project is another way to apply agile’s speed and adaptability to other projects.

Another is the concept of cross-functional teams, allowing communication for better efficiency. Continuous integration also helps with transparency between different aspects of the project, which leads to greater efficiency. There are also information radiators, iterative and incremental development, Scrum meetings, timeboxing, use cases, user stories and so much more. All of these things help companies get things done in a way that’s different from than traditional waterfall methodology.

In order to have the transparency and collaboration needed to work in an agile environment, where everyone knows what done means and when the team is in fact done, the right kind of tools are required. ProjectManager has a real-time dashboard and planning features that are fed with metrics as they happen, so all members of the team are on the same page. See how it can help you get things done more efficiently by taking this free 30-day trial.