Here is an example of a definition of “done” I have used with one of my teams:
- All acceptance criteria have been met for a user story.
- All core regression tests have been run, and all spotted regression bugs have been fixed.
- All particular regression tests within the areas where code changes occurred have been run, and all bugs have been fixed.
- The code, along with any other artifacts necessary to run the application on any environment—whether it be test, pre-production, or production—is in the artifacts repository and is ready for a one-click deployment.
The Critical Skills Required to Achieve a High Commitment-to-Progress Ratio
In the following section, I will examine and describe the skills that should be fostered in team members who strive to achieve a high commitment-to-progress ratio. I’ll explain why these skills matter and how they contribute to the high commitment-to-progress ratio.
Awareness of Quality
I was once asked by the managing director of an Internet startup to better organize its software development processes. The directors of this startup attributed the low quality of deliverables to an unstructured way of developing, which they hoped to improve by introducing Scrum. After I introduced the basics of Scrum to one of the startup’s teams along with a product owner, we began the first iteration. The team had been working before using two weeks for development and one week for testing. Because the startup directors wanted to quickly ship features, the team focused on knocking off as many of them as possible within two development weeks in order to meet management expectations. Quality was not emphasized during these two weeks, because the one week of testing to follow supposedly would ensure quality.
It was difficult for the team to estimate how many items they could finish completely. Previously, the team was only estimating how many items they could develop. The team members perceived quality as an external task to the development activity. No one wanted to hear about being responsible for quality while developing. The only acceptable solution for them was to hire more testers, thus raising the amount of bugs reported per day. Their commitment-to-progress ratio was nearly stagnant and stuck on a low level. In this case, you cannot accurately assess how much you can finish when you have no idea how to deliver a completely working item. I worked with everyone in the company to change the way they understood the relationship between quality and software development (which is a long story in itself) and the situation gradually improved as exemplified through the increasing commitment-to-progress ratio.
Software development quality is determined from a variety of aspects, one of which is testing. As a result, if you as a team member care about quality, then you will continuously look for ways to link up design, deployment, logging, and other development processes with finding bugs earlier, reducing their scale of impact, and preventing them in the first place. By doing so, your code will become more reliable and your intuition will fit better to the actual progress. Based on my experience, I find that teams lacking quality and improvement awareness are unable to achieve a long lasting and high commitment-to-progress ratio.