How to Give Actionable Feedback in Agile Development

This is a guest article by Tarasekhar Padhy from zipBoard

Agile thrives on feedback. The values and principles of Agile promise a process that delivers increased ROI with decreased loss. The important thing is to keep the agility alive and that solely depends on how well everyone communicates. Stakeholders, clients, the development team, external reviewers, and nontechnical collaborators need to provide each other with valuable feedback.

One can easily list four to five points regarding the importance of feedback, especially when the Agile methodology is considered. Since that's been addressed many times, this article will cover feedback in Agile development: how to give/receive it, how to process it, which mediums to choose and why.

Giving and Receiving - Feedback that matters

During the testing phase of any product, QA managers or testing managers can definitely agree with the statement “not all feedback is useful.” A small section of the feedback that you receive translates to user stories worth addressing and the rest is their personal opinion. Of course, while giving feedback one can make sure to communicate effectively, but what to do when you are at the receiving end?

Tips on giving feedback

• Give feedback after it’s asked for. Chiming in during the developmental phase with suggestions and ideas will irritate the developers and collaborators.
• Ask questions first. Try to understand why things are this way and the thought process or the justification behind it.
• Only relay the things under the receiver’s control. Giving design feedback to the developer will not help in any way. In general, feedback is usually received by one person who classifies the received reviews and forwards them to the right collaborators.
• Be concise and specific with examples. While suggesting something, give proper reasoning and provide some examples for the same.
• Give feedback that will improve the product. Any feedback that you provide should be aimed at that.
• End with a request for opinions. It’s important to know how the receiver of the feedback feels about your ideas and suggestions.

Example: Feedback like “the homepage doesn’t feel good” will not help the dev team. Instead say something like “the homepage doesn’t show information that's relevant to me as a user.” The latter helps isolate the issue that the problem lies with the content or the way content is presented.

Tips on receiving feedback

• Listen to understand and not to reply. Figure out the intent behind the feedback.
• Be honest and open while providing justifications for your decisions regarding the design.
• A good reason provided to the reviewer should precede refuting suggestions as to why their opinion and feedback will not work well.
• Try to figure out why particular feedback is given. Ask detailed questions in regard to that element of the product.
• Propose off-the-top alternatives and see if the reviewer is inclined to accept any of all them. It will help understand what is desired.
• Follow up. If there are a few suggestions that require a bit of research on your part, hit pause on that conversation and get back to that later.

Example: The proper reply to a client's feedback that the website homepage contains a slider and it’s distracting should be more detailed. Replying with our research suggests that a visitor is 3x more likely to sign up if there is a slider beats okay, we will change it or we know what we are doing. Providing justification as to why things are the way they are solves a lot of issues and clears confusion.

Talking to the right people: Getting feedback is crucial as it determines the direction in which the development process will proceed. In an Agile environment, it also determines the investment and the ROI, massively. It is important to take feedback from the people or groups who qualify the requirements for the same. Depending upon the phase of the project in Agile frame, the individuals vary:

• Initiation phase: Industry experts, investors, market experts, SMEs, technical professionals.
• Planning phase: Consumer experts, product owner, selected focus groups, marketing team, finance department.
• Execution phase: Focus groups, external reviewers, development team, end-users.
• Closure: Existing customers, selected focus groups, industry experts.

Choosing the Correct Medium

Due to the pandemic lockdown, face-to-face meetings have been replaced by video calls. However, not all kinds of communication require direct personal contact with the recipient. An Agile team uses synchronous and asynchronous methods of communication judiciously and it makes the whole process effective.

Synchronous Communication

A phone call, a video call, or any form of live communication is considered to be synchronous communication. Primarily, synchronous communication is preferred in the brainstorming phase. Physical meetings, daily stand-up meetings, phone calls, and screen-sharing meetings are examples of synchronous communication. Most of the official forms of communications, for example with senior executives and/or clients, are preferred to be done synchronously.

Example: If the next step is to create an outline for the project and bounce ideas, then the preferable way is a video conference call. Opting for an asynchronous form of communication helps everyone see each other's views quickly.

Pros

• It's immediate and live.
• There's no waiting to know your team’s opinion.
• Ideas are quickly generated.
• Information and updates are quickly exchanged.

Cons

• Sometimes they're longer than necessary.
• Setting up is challenging.
• It may feel like a chore if attendance is compulsory.

Tools that can be used: Microsoft Teams, Zoom, Cisco WebEx, Skype, Slack, Whereby, BigBlueButton, BlueJeans.

Asynchronous Communication

Messaging, annotation, markup, and recorded videos are considered to be asynchronous communication. Asynchronous communication is a great way to exchange daily updates, feedback, and reviews. In many organizations, meetings have been replaced by daily update messages, which has even resulted in added productivity. Quite a lot of meetings could be trimmed down if asynchronous communication is adopted.

Example: Text messages are the preferred way to share EOD reports. It’s a quick and efficient way to let everyone else know what you were up to. Asynchronous communication saves a lot of time by omitting a lot of meetings this way.

Pros

• It saves a lot of time.
• Scheduling is not required.
• The visual form of asynchronous communication is quite powerful.
• Sharing daily updates is easier.
• Meetings are trimmed down and more efficient.
• Giving and receiving reviews and feedback is easier.

Cons

• Nonvisual forms of asynchronous communication are somewhat inefficient.
• Sometimes you have to wait.
• It's meant for quick updates only.

Tools that can be used: Chanty, Slack, Hangouts Chat, Flock, Convo.

Processing Feedback - making it actionable

Receiving the feedback is the zeroth step of the process. The real task begins when one has to create actionable tasks out of the received feedback, prioritize them, assign them, track them, and get reviews again. In many cases, a lot of the received feedback is dependent on the personal preference of the reviewer. These reviews don’t necessarily provide proper direction to the developers and designers in regard to product development.

The real aim is to separate the unimportant feedback from the significant and act on it wisely. After feedback is received and collated in one centralized place, there are two immediate things that need to be done:

1. Convert them to actionable tasks and assign them.
2. Prioritize and track them.

For example, if a reviewer states that an aspect of the functionality is not solving their problem, that concern should be prioritized over a comment that “the colors are too bright.” Moreover, the issue of functionality should be assigned to the concerned developer along with all of the details.

Task Management - who does what

Each point in received feedback could be made into a task that can be assigned to one or multiple collaborators. However, there are many other aspects to tasks created from the reviews. After the feedback is converted into actionable tasks, they should be assigned to collaborators on the basis of priority. Not only that, deadlines need to be set and then the feedback has to be collected yet again after the changes are deployed.

Bug tracking is a really important part after the tasks are created and assigned. This helps the team create proper documentation for the bugs and issues that reduces the probability of their recurrence. Recently, more and more teams are adopting visual bug tracking tools as they are easier to operate by both technical and nontechnical stakeholders. The following are the steps that one can follow for efficient task management.

• Creating a task: Add details about what’s wrong and what needs to be fixed/done.
• Assigning: Assign the task to the concerned individual. It should contain details like priority, deadline, expectations, etc.
• Tracking progress: Various phases can be tagged on a task like ready, assigned, terminated, expired, in progress, verified, finished, paused, etc.
• Documenting: Complete analysis of the bug or issue after the dust settles. It helps the team avoid similar complications in the future.

A good task management tool is a good investment because:

• It helps everyone know what is important.
• The collaborators know what they need to work on.
• The deadlines are known to everyone.
• Bug tracking becomes easier.

Tools that can be used: Asana, Trello, Teamwork, Airtable, Wrike, Hive.

Backlog Prioritization - the impact of a task

Based on the phase of development, the horizon of business growth, and a few other factors, the prioritization of tasks takes place. For example, if the aim is to get the highest level of customer satisfaction, the Kano model is preferred. However, if the focus of the team is to release the product, the MoSCoW model could be closer to your ideal. Backlog prioritization helps the development team define short-term and long-term goals. After feedback is received, they are prioritized based on the severity of their impact on revenue, customer satisfaction, and future goals.

Choosing the right backlog prioritization technique for your present status will determine how quickly and efficiently your team can achieve goals. Proper prioritization also helps with making the team more agile and more adaptive to changing conditions. Below are a few backlog prioritization techniques and their USPs:

• Kano Model: Preferred to create the outline. Aims at customer satisfaction. Tasks are directly connected to their effects. Easy to maintain.
• MoSCoW Model: Aimed at faster product development. Has its roots in Agile. Tasks are prioritized on software release requirements.
• Cost of Delay: Puts a number on each of the tasks in the list. Aims at reducing financial loss. Helps while developing a competing product.
• Net Present Value: Considers the investment also. Helps improve resource allocation. Market value is the primary metric.
• ICE prioritization: Simple implementation. Puts a number in front of everything. Prioritization is based on impact and available resources.
• RICE prioritization: Consistent metric system and easy implementation. Aims at customer satisfaction. Helps with proper resource allocation.
• Story-mapping: Focuses on customer’s journey. Preferable to use while creating a new product strategy. The whole picture is visible at once.

Tools you can use: zipBoard, Jira, Confluence.

A properly prioritized backlog helps the team with

• understanding the long-term and short-term goals,
• knowing the next thing that needs to be done,
• adjusting the organization's goal,
• making predictions and creating a timeline.

Wrapping up

Feedback is information that is received from testers, users, the development team, the non-technical stakeholders, and clients. This information is used to make the product or service better by improving existing features or adding or removing new ones. Feedback in Agile is as important as the driver in a car. To operate with the principles of Agile, it is important for all the collaborators to communicate organically and spontaneously.

What is even more important is how an Agile team should react after receiving and processing the information. Building a functional feedback loop into the development process is imperative to make the team Agile. Feedback in Agile is vital for the business value of the product, enhancing customer satisfaction, minimizing losses, and increasing revenue. Moreover, feedback in Agile development makes the organization reactive to externally changing conditions. As a result, it makes the team more adaptive, and long-term growth becomes more attainable.