Defect Prevention Using Agile Techniques

There are innumerous ways to slip up when creating a user story. These can lead to implementation defects if not validated before development. Details that are apparently clear in the head of the Business Analyst, or even the client, could end up not being properly expressed in the description of a story.

Since preventing defects in software as early as possible is desirable in any development project,  there are many techniques available to prevent these issues before they manifest themselves, it is worth reading the new book by Gokjo, Fifty Quick Ideas To Improve Your Tests. Two of these techniques have proven to be very valuable to us in the maintenance of quality in our project: Kick off and Desk Check of stories.

As stories under analysis are still open to suggestion, a good idea is for the team to have a meeting where the Analyst (or another team member with good context) presents the upcoming stories, their origin, the proposed value and why they are required. This gives the team an opportunity to discuss technical details, ask questions to clarify the requirements, and evaluate if the size of the story is appropriate. This feedback can be used to split the story where appropriate, or add more detail and examples to clarify the areas that caused confusion.

Kick off

A Kick off takes the form of a checklist that contains several items to be verified before starting the story’s development. This list includes verifications such as: is the analysis of the story really complete enough to start development? What technical considerations must be observed during development? Do we already know about the visual design? How to handle error and help messages?

Another common problem is that the developer may have some assumptions but not share or verify them with the Analyst (communication failure). Having this initial team chat allows sharing concepts and objectives without overlooking important details, and adds more context from the point of view of people in different roles.

In an ideal scenario, the participation of Business Analysts, QA and developers is fundamental on the kick off given that everyone becomes aware of the functionality being developed, turning the debate more productive and useful. Check out our suggestion for a kick off checklist below:

Kickoff Checklist

Participants: Business Analyst, QA, Dev pair

• Is the analysis for the story done?
• Is the QA review of the analysis done?
• Is the story complete with details and all the relevant information?
• Is the value of the story well understood?
• Is the story a dependency to future stories?
• Is there a technical debt related to the story?
• Are there wireframes for the story?
• Are there error messages and other related user feedback detailed in the story?
• Are there help messages or other labels defined in the story, were they reviewed?
• Is the story size okay?

For the same reasons justified on the Kick off, the Business Analyst, QA and developers must be present to broaden the debate on questions and problems during the development. It’s important to remember that, particularly for large stories, verifications can be made during development in order to make sure things stay on track. Be sure that this feedback does not exceed the scope of the story, and if they make sense, it’s likely that the analysis of the story was not completely accurate.

Desk Check

A Desk Check is a practice to be used for verification when the pair of developers believe the development is complete. In the list below we see verifications such as: Were unit and acceptance tests implemented? Did you invite someone to review your code? Did you try out it in all the supported browsers? Such questions are important to help avoid headaches in the future. For example, your feature may work beautifully in Chrome but not show up at all in Internet Explorer because it doesn’t support the Libraries or HTML you used.

Desk Check Checklist

Participants: BA, developer, interested parties

• Does the story have enough test coverage?
• Did you invite another pair to do a code review?
• Did you manually test the story?
• Did you check whether the story may have impacted something else?
• Has all the acceptance criteria been covered?
• Does the story need some sort of feedback or correction?
• Did you do a complete user journey through the story?
• Is the UI interaction consistent with the rest of the app?
• Does it work with the main browsers?
• Is the text in the story consistent with other texts and labels in the app?
• Did you check text content for grammar errors?
• Is the color scheme consistent with other colors in the app?

One could say that most defects are found during the desk check, for obvious reasons, as that is when the story is delivered and when it is finally possible to do a preliminary test of the completed functionality. However, we recommend giving special attention to the Kick off, as this is where misunderstandings occur and things could end up being implemented differently from the ideal.

It's worth emphasizing that these checklists should not be rigid, nor written in stone to be followed to the letter. The important benefit of this approach is to check whether the important steps were taken into consideration during story development. Another thing to remember is that these checklists should be personalized, since each project has its own peculiarities and needs. Create your own lists and see what benefits you gain right from the start. Keep this habit so that it is not forgotten over time.

Do you practice defect prevention techniques that you would like to share?  Share them in the comments section below.