You have been in this situation. You work on a user story, the story has been estimated for 5 story points. And you know how it goes, the team or the manager translated that to 20 hours of work. While thinking about the code that is needed, you see that existing code, created in previous user stories, needs to be refactored to accomodate the new bits. That is, if you want the code base as a whole to be of high quality. If you are in a truly agile project, you inform your team mates that you will need to refactor existing code and you will need two extra days for the user story. They’ll understand, they trust you on this, and they value a high quality code base as much as you do. One of them may volunteer to assist in a pair-programming way.
However, in most Scrum project there is a manager involved. In the end, you will have to go to the manager and say “we will need two more days for this”. You will have to add that you can do without the two extra days, at the cost of creating four days of technical debt and an ugly code base. The manager will weigh the two extra days against the disappointment of the product owner when they learn this feature will not be in the next demo. It wouldn’t be the first time this happens, so the manager says “no extra days, just make the code, we will refactor later”. We know what that means. In the end, the codebase will contain ugly code with your name on it. All you can do is write a “// WTF” comment in your own code.
In order to prevent all this, we need to add something to our agile toolbox: We need to take quality of the product into account.
A typical Scrum project starts from functional requirements, documented as ‘user stories’. Scrum has no provision for non-functional requirements, i.e. the requirements other than ‘what should the product do’. In the ISO 25010 standard non-functional requirements are defined in detail. They include reliability, security, maintainability.
I don’t want to go into much detail here. Let’s define ‘product quality’ as all non-functional requirements, that is, all requirements except the specifications that are in the user story descriptions. Quality does include the aspect of ‘does the product do what the user story specifies’. This is what is called ‘Definition of Done’ in Scrum, or at least it should be.
At the start of a project, we should list quality requirements. Some may be relevant, some may not. Code maintainability is almost always relevant, portability may not be. When you start programming a feature, you check how quality requirements affect your code. Often, you’ll see that the new code is more or less independent of existing code. You don’t have to spend time refactoring. Sometimes, you’ll find that your new code will affect existing code so you’ll need to refator. Or, your new code will necessitate complete rewriting of parts of the existing code. Because you have stated the quality requirements at the start of the project, there is no need to discuss the extra work, you just inform your coworkers. Or better still, as the work is more complex than you thought, you go through the code with one or two coworkers in review- or pair programming mode.
When you define the quality guidelines for your project — or your organization — you don’t go for maximum quality. You go for optimal quality. Optimal quality is defined as the point where adding more work doesn’t give you much higher quality, but spending less time does make quality significantly lower. For security and reliability you’ll probably aim at a higher level than for usability or portability.
In projects in which story points are calculated at the start, you’d need to go through existing code in detail during the ‘planning poker’ meeting for determining the extra work needed for refactoring. This adds to the total time needed for the feature, and thus for the project as a whole. I suggest you don’t do story points or planning poker. They don’t serve a practical purpose, they add an extra meeting to your project, and a meeting is time that you don’t program. Not doing story points makes your project more agile.
A project taking quality into account would look like this:
- Project startup. I prefer this to be a Project Startup Hackathon.
- Write the first few user stories or features. You can add to them during the project.
- Write a single page document on non-functional requirements, aka ‘quality’. Specify which requirements matter most, and which don’t. Specify to what level you want to maintain code quality. This can be done by providing a maximum number of hours of technical debt that is allowed in the project. You may have such a document in the organization, so you don’t have to spend time on it in your project.
- Start working. For every user story or feature that you do,
- estimate refactoring work
- verify the product meets al requirements
The last point is mostly the ‘definition of done’, including the quality requirements.
- Finish the project. Because at every point in time, you’ll have a viable product that has been deployed via continuous integration, the end of the project is an arbitrary moment when someone says “it’s done”. This can be because the users or customers tell you they have what they wanted, or it can be that the management decides enough time and money has been spent. Hopefully, it will be a combination of the two.
During the project, you will find code that is not directly related to your new code but that you do think needs refactoring. You may want to add a line to your quality document on how to handle this. I suggest that refactoring — removing technical debt — is done as much as possible. On the other hand, you don’t do refactoring on code that has been thoroughly tested and has been used for some time, thinking ‘if it ain’t broke, don’t fix it’. I like to rely on the judgment of programmers here.
So far, I have discussed programmers creating code. In an agile project, a team of programmers, intereaction designers, grahpics people, testers, users and others work together creating the product. What I write in this article also goes for designers and testers. It goes for users in the project who provide just in time specs. For all of them, there are lines in the quality document that specifies how much time and effort should go in the quality of the product.
A good programmer is happy when they know they make high quality code. Keeping programmers happy keeps them motivated and prevents them from leaving. High quality code means lower maintenance cost in the future. In the long term, it is cheaper to produce high quality software.