Definition of Done

definition of done checkmarkIn software development, definition of done specifies all of the conditions that a software product must satisfy to be accepted by the customer. The main driver for establishing DoD criteria is increasing the quality of the product being delivered.

The DoD might differ from product to project, and usually the team (together with client representative) is responsible to figure out the exact criteria that are needed/are going to work for specific project at hand. However, it is good to have a good starting point that becomes cornerstone for the team’s work. Here is our initial Definition of Done for agile projects:

User story:

  1. Code review accepted
  2. Automated tests passing
  3. 80% unit test coverage
  4. Acceptance tests automated and passing
  5. Functional tests scenarios created and reviewed 
  6. Integration test scenarios created and reviewed
  7. 80% of functional and 60% of integration tests automated
  8. Data migrations scripts created and tested (forwards and backwards)
  9. Documentation written and reviewed


  1. All stories in scope merged into sprint branch
  2. All tests passing
  3. Demo performed and Product Owner accepted the sprint functionality
  4. Performance tests passed
  5. Exploratory tests passed
  6. No bugs/regressions on the sprint branch



What makes a good user story in agile software development?

user story planning


Working with our clients, we frequently get asked about how a perfect user story should look like in order to facilitate the cooperation between business and development teams. Below is a small write up on the subject based on our longtime experience.

User stories are central element to the agile/scrum methodology as they define every piece of work being done by an agile team. There are several important guidelines that needs to be followed to create proper user stories that fit well with the overall process.

Components of user story

The user story is an expectation about the system expressed from the point of view of the end user. The crucial elements of the story are:

  1. The role of the user in the system that is going to benefit from the system
  2. The short description of what the goal or intent of the user is
  3. The specific business value/benefit that we expect to achieve by implementing the user story

The user in the first point does not necessarily need to be the end user of the application itself. It is the user that is going to benefit from the change. In can also be an admin or even a person from the development team.

One should avoid putting into the description of the goal details related to the specific implementation, in particular there should be no references to UI elements or specific technologies.

The business value statement will allow the team to focus on the big picture business expectation instead of specific system functionality. This allows the development teams to come up with creative ideas and not to go off the rails while executing the story.

In addition to the elements mentioned above, a user story should contain acceptance criteria, which are high level test criteria that confirm that the story works as expected. The acceptance criteria can be both functional and non-functional. Please note that this does not need to be full suite of tests for the feature – this is going to be developed by the agile team during the implementation.


Several examples of well-phrased user stories:

  • As a site visitor I can create a new account so that I can get personalized experience on my next visit
  • As an admin I can create a new user group so that I can assign permissions to the user faster

A user story should be small enough to be executed within one sprint. If the team believes that the user story is too large it needs to be split. The reason is that in agile methodology the work is being delivered incrementally in sprints, which are allotted time slots of team’s work. Each sprint should result in delivery of business value as defined by the user stories included in the sprint.

How to organize stories?

To enable better management of large user stories there were additional story types introduced: enablers, spikes and epics. An enabler is a story that is not delivering business value at the end of the sprint. Instead, it enables the team to deliver the value in the subsequent sprints, building on top of the outcome of enabler story. Also, the work related to system architecture, refactoring can be captured as an enabler.

The enabler stories should not be overused though: the strength of the agile process is in rapid delivery of the business value and feedback from the actual users. A series of enablers followed by a single user story that brings them to the user would be contrary to the purpose.

A spike is a research or investigation work that needs to be performed to properly design or estimate an approach or user story. The purpose of this story is to reduce the risk or uncertainty related to use of specific technology, estimation of a user story or a functional scope. Spike might also include building a small prototype.

Also, the user stories can be organized into epics, which are larger initiatives that group individual user stories, spikes and enablers related to particular business area.

NG Logic Announced a Top B2B Company in Poland

An IT solutions company, we formed 15 years ago and have seen rapid growth and success ever since. We specialize in mobile and web applications, integration, and IT audit, all of which are led by expert team members. We believe that the best asset to any company is to have smart people working behind the scenes and that is exactly what we have built in the last decade to create an innovative and driven team that finds solutions to any problem our clients are having. Because of this, we have recently been named a Top B2B Company by Clutch, a ratings and reviews firm based in Washington D.C., notably for our high performance as a web developer in Poland. Clutch conducts verified reviews for thousands of companies around the world by interviewing past and current clients, as well as by using an objective scoring system that judges based on factors such as market presence and industry recognition.

One of our clients, the VP of development for a nonprofit, had this to say about us: “They’re good at understanding what you’re trying to achieve and they work as part of the team. You can give them general directions around certain areas, and they’re able to think through it with you and come up with solutions.” Another one of our clients, the CTO of a company that builds software used by engineers, said this: “They’re very strong developers and have good communication skills. They interact with the US team seamlessly and are a good addition to the capacity of the team.”

In recent years, we have started changing our focus to newer and more advanced technologies, as the future is headed in that direction. We are constantly adapting and learning new ways of helping our clients, which gives us an edge that isn’t seen in most companies. As we continue to grow and change, we are still remaining loyal to our main goal, which is simply to provide the most reliable and efficient IT solutions that we can and we plan. For more information on us, as well as full reviews, check out our profile on Clutch.