5 Ways Testers Can Mitigate Practical Risks in an Agile Team

[article]
Summary:
Testers who analyze quality in every aspect of the team’s deliverables also have a responsibility to mitigate risks and practical issues that are bound to come up, and help the team succeed in their product as well as at being agile. Here are five such issues that testers can help the team alleviate or avoid.

Let’s say an agile team has a user story to develop a webpage in a sprint. The product manager mentions only the mandatory fields of the webpage in the story's description while scoping it in the sprint. The developer works on the story for a couple of days and adds the listed fields on the page, but because he going on leave for a few days, he only provides the basic form fields without any input validations or error messages on the page.

Once back from his vacation, he checks in the code and shares it for testing a day before the sprint ends. The tester tests it for a day and raises some minor severity issues. In the final sprint demo, the product manager points out that a number of fields are missing on the webpage. Because testing is not complete yet, the story is tagged as a spill-over item to the next sprint. Few UI changes are added in the next sprint's scope, along with the pending validations and error messages.

What do you think went wrong in this story?

Agile is all about controlling and minimizing the typical risks of conventional software development techniques. When working with agile, we have the flexibility to control our direction and steer our path based on unforeseen and unplanned changes and events.

But it is the same flexibility and dynamic nature that makes agile prone to many risks during the project.

These risks are the practical issues that any agile team is bound to face eventually and that, if not handled quickly, may lead to failure of the sprint or the agile process as a whole. Testers who analyze quality in every aspect of the team’s deliverables also have a responsibility to mitigate these risks and help the team succeed in their product as well as at being agile.

Here are five such issues that testers can help the team alleviate or avoid.

Risk 1: Ambiguous User Stories

Agile assumes that each user story is a unit of work to be achieved in a sprint. The user story needs to be granular enough and have all relevant details and context when scoped. But because agile also recognizes changing requirements as likely, this gets used as an excuse to not list the requirements for each user story or give details early on. This leads to ambiguous requirements, often resulting in low-quality outcomes and rework on the feature.

The actual aim of agile is to work on a feature based on the best knowledge of its requirements at the given time. The sprint format in the Scrum process leaves scope to work on a feature again if enhancement is needed. But that is based on collecting all available information for one story and only then scoping it in a sprint. If that is not ready yet, the story should not be scoped in the current sprint.

Testers in an agile team have the responsibility of reviewing user stories when they are being planned for the sprint and requesting clarification from the product management. Similarly, developers can raise questions about technical and design details they feel are missing and get them defined during planning sessions. Based on these details, testers will create their test scenarios around that user story, and developers will create their implementation design and keep asking more questions if needed over the next few days of the sprint.

In the example at the beginning, the tester could have raised the concern that the user story did not have complete details for the webpage to be developed while scoping it in the sprint. The developer should have asked about relevant validations and error messages needed, as well as some broad layout details to work with.

User Comments

4 comments
Tim Thompson's picture

This article hits the nail on the hat. Nice write-up of what is wrong with Agile in reality. Another issue is product owners not committing to acceptance criteria at any point claiming that "we are agile" and "can hit this next iteration"...and then never do.

During the consultant's training sessions Agile sounds great. Agile is to management the panacea that fixes all issues. In fact it is just a tool that fosters failure to plan and cranking up the baseless expectations of delivering features faster. And what happens when time is of the essence? Quality gets cut, bug fixes are postponed, and devs are put on yet another story to cram more half-baked features into a release. Agile often accomplishes only two things: higher stress levels and worse quality.

September 26, 2015 - 2:17pm
Nishi Grover Garg's picture

Thanks a lot @Tim for your kind words. You are right in saying that Agile is becoming just a sought after keyword by management as the "silver bullet" get everything done. But in actual turns out to accomplish less and less each day if the above points and scenarios are not taken into consideration soon enough.

September 28, 2015 - 3:33am
Sanat Sharma's picture

Most of the projects running in Agile have so much loop holes in the execution that the end result is nothing but a stressfull team and customer issues. This article talks a lot about the responsibility of Testers in Agile development. I do agree with the fact that Testers can improve the quality of the product but most of the times, it is Product Managers who has no Release backlog / Product backlog items in their bucket which drives to a complete failure of the product. And for this, the blame goes to Engineering team. My view is that a Product Manager always play a major role in the Agile development as well as in success / failure of the Product line.

Sanat Sharma

September 28, 2015 - 7:05am
Dave Maschek's picture

Thanks for a thoughtful article. I worked on a team that was highly Agile and on other teams that were less Agile. The tester can try to influence the team to be more Agile, but cannot compel others to do it if they are unwilling. What the tester must do in every situation is work with the team to create the best possble software. Good testing technique, hard work, flexibility, open communication and cooperation go a long way.

 

November 13, 2015 - 3:27pm

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.