Using reaction to a comment in Azure Boards to improve team performance

In Azure Boards, you can add reactions to any comment on any work item type. At first, this can look like a silly improvement and the use case that fist came to my mind was to give thumbs up/down on a comment just to spare some space in the discussion section and to use fewer words in everyday communication. Also, another use case is the voting process for some idea that is revealed as a comment in the discussion section.

But what if we could reuse this feature in our development process to gain some speed in communication and to write fewer work items and be more productive?

Let’s imagine a team of two developers and two testers working on the same project or feature. There are several User Stories opened and some development and testing are required on them before delivering the finished feature into production. The team decided that they will not open child Tasks under User Stories because this is overhead for the team. After all, mostly the Task description contains the same details as a User Story and the Team doesn’t want to waste time dealing with the Tasks.

This is a legitimate reason for the Agile Team to take such a decision since the idea of an Agile Team is to reduce waste time and gain performance. It’s the Team who decide what works best for them in the process as long as they deliver on time with great quality build in.

Both developers take one User Story to work on. After they finished, they set the status of the User Stories to Resolved and assign the story to the tester. They repeat the same process with other User Stories while the testers perform the quality check according to the acceptance criteria and also try to break down the feature with some edge cases that came to their mind. After some exploratory testing, testers found some issues regarding the feature implementation.

They can open related Bugs and add some description along with retro steps on it and assign the Bug to the developer, but since this is a small team, they don’t want to introduce complexity by managing the Bug work items for internal User Story testing. They decided that Bugs will be opened only for the issues found in the production environment. Their choice is a very good decision because Team will gain performance by saving time with less work item management and they will be focused on resolving the issues.

So, the testers are writing issues as a comment in the discussion section in the user story.

Some user stories are implemented on a developer’s bad day and contain 20+ comments in the discussion section and the deadline is approaching so we need to add more resources into the effort to fix the issues. So, the question here is how to track the changes in a single user story when multiple resources are involved? Here is where reactions come to play. The Team decided to seat the ground rules before diving into work. 

A developer that takes an issue described in a comment to resolve will add a smiley reaction to a comment. In this way, other developers will know that this issue is taken, and the testers will know that developer is working on the issue. 

After the developer finished the fix on the issue and delivers changes to the testing environment, he will add a thumb-up reaction to the comment. In this way, the tester will know that the fix is delivered to the testing environment and he could verify the issue. 

If the issue is fixed, the tester will add a heart (love) reaction or thumbs-down in case if the issue isn’t fixed. 

In this way, everyone has the track on what to do and we have control of the process and what needs to be done to deliver the final result to the production. The result is the same as we had opened related bugs, but the reaction workflow required less time to manage. The cons for this approach are that you lose the reporting on how many bugs are reported in the sprint or on the specific user story (you can look the count the comment numbers on a work item, but no one can guarantee that every comment is a bug). 

In conclusion, the reaction workflow is not the silver bullet and you should always aim for the best practices in your development process, but sometimes desperate times call for desperate measures and when you are in lack of resources and on a deadline, switching to a reaction workflow to resolve the issues in the sprint could save you time and allow you to deliver on time without losing your mind.