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.
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:
Participants: Business Analyst, QA, Dev pair
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.
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.
Participants: BA, developer, interested parties
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.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.