How I deliver quality as a developer without impacting deadline

As developers we have a primary goal during any given sprint to deliver functionality in one form or another by a given date. That requires us to come up with an adequate estimate of the level of effort a task will take. In many cases this can be done with a reasonable level of success, success being the estimate given matches the time to develop and complete the task. However, there are times when we underestimate the level of effort and end up needing to make sacrifices in place of a looming deadline. These sacrifices often are taken at the expense of quality of the work delivered. Why is this? Because quality is the work that is not immediately visible by management or by the customer. The cost of trading quality for time ends up creating unwanted future work such as tech debt.

We can’t always avoid these cases where work is underestimated but we can take actions to minimize and reduce the occurrences.

First we must divide tasks into categories to better understand where to apply a greater focus. This can be done with a metric such as level of effort (LOE):

Category A: These can be bug fixes, Priority 4 tickets, text or CSS changes. Anything that doesn’t touch more than 5 or so lines of code or more than half days work.

Category B: These are medium development tasks (between 1–3 days), and large tasks (anything greater). These tasks are where the focus on quality becomes much more important and where we are making, in some cases, significant changes to the code base.

Now that we have our tasks categorized we need to have a development process that will ensure quality. This process should look something like:

  1. Design and collaborate with peers. Establish a good mental image of the work that is required and parts of the code that will be affected.

2. Get it working. Develop what I consider a first draft or proof of concept (POC).

3. Manually test out the bugs.

4. Write unit tests.

5. Get it right. Refactor for reuse and maintainability.

6. Rerun unit tests.

7. Retest manually.

8. Peer code review.

9. Push to an integrated environment for more testing.

We must ensure sprint estimates include not only time for unit tests and manual tests but also time for refactoring and code reviews. Most developers spend less than 50% of their time actually coding we you factor in meetings, build times, CI pipelines, etc. So a poor estimate is one based solely on coding time.

When we find our selves routinely coming down to a deadline and resigning to marking a task complete at the “get it working” phase then we are sacrificing quality and adding to a looming future cost. We can help avoid or at least help minimize future cost by making a deliberate attempt to evaluate how we are estimating tasks and by ensuring these estimates include time for quality. Get it done right.