What do you do if you need to gather feedback from multiple stakeholders in Agile projects?

The essence of gathering multifaceted feedback in Agile environments lies in its critical role in keeping the project aligned with its goals while catering to the varied necessities of all involved. It's a balancing act that demands an environment where openness, transparency, and a readiness to pivot based on received insights prevail. Creating a space where stakeholders feel their contributions are not just heard but are instrumental, lays the groundwork for a project's triumph. Adapting your strategies to the unique characteristics of your stakeholders enhances the quality of feedback you receive, turning it into a cornerstone for steering your Agile project toward its envisioned success. Agile, is characterized by its iterative cycles.

*Determine who needs to be directly involved or informed, such as the product owner & dev team or other departments. * Implement sprint reviews & retrospective meetings for progress updates & stakeholder input. * Use Collaborative Tools like JIRA, Miro, & Trello in virtual meetings for interactive feedback. * Plan sprints for user testing to gather feedback. * Host workshops, discovery sessions, & backlog refinement with stakeholders. *A communication plan isn't usually part of agile methodology, but it's critical. I recommend including communication activities in your sprint planning as they directly affect a project's success. These strategies aim to build trust, ensure transparency, manage risks, & deliver a stakeholder-aligned product.

The two important steps here are: 1. Identifying the relevant stakeholders. So define your ICP, i.e. Ideal customer profile. Narrow down ICP, if you are seeking inputs on a sales enablement tool, define the stakeholder e.g. A Sales VP, in a growth Startup, with X number of BDRs, Y revenue, operating in SAAS so on an on. 2. Seek only relevant/serious feedback. Just ask them if they are willing to pay (in terms of money, their time, their resources), half of the irrelevant feedback will vanish. Are they ready to commit to a pilot or actively involve from tomorrow if you act upon their feedback. This is hard, but if you don't do this you will gather feedback like Global warming which we know is hard but so abstract that you can't act upon it.

When identifying stakeholders, make sure you've identified which stakeholders are primary for your product's success. In my experience, I've found that your most important stakeholders are not always the loudest nor the most forthcoming. Multiple stakeholders will generate exponentially more requirements and ideas, so by noting requirements needed by the primary stakeholders, you can more easily prioritize and identify tradeoffs for a faster release.

Identifying stakeholders, engaging in discussions on what is expected or improved to satisfy their needs. This has to be done on iterative basis through arrenging workshops/demos. This is the most crucial part of any agile project. Iterative development is carried out based on these feedbacks and expectations. Utilizing tools is a good way to overall manage it efficiently.

Workshops are indeed great. But you can also try out involving stakeholders in UAT (User Acceptance Testing) activities to validate project deliverables against business requirements and user expectations. Gather feedback from stakeholders during UAT sessions and address any issues or feedback before finalizing deliverables.

In my experience, workshops are a great way to get feedback from stakeholders/groups. Workshops are great for collaboration, getting on the spot opinions and clarifications. It helps to have an agenda and pre-reads sent ahead of the workshop so that stakeholders come prepared to engage. Another thing that helps get high levels of engagement is to use visual tools/platforms such as Miro; Mural, Jamboard, electronic whiteboards which allows every participant to be included and involved in the whole process.

I think one of the best things you can do is run a workshop. This will not only help you gather feedback from stakeholders, but will also make them feel involved in the process. Making them part of the process is essential for the success of the project and to increase the probability of obtaining their support in critical phases such as the definition of the different releases and the subsequent UAT stages.

When it comes to gathering stakeholder feedback, there isn’t a “one size fits all” approach. Your approach must be tailored to how your stakeholders engage best. Some stakeholders do well with a “blank slate” and a full day workshop to iron out all of their needs. Others can’t allocate a full day and may like someone to have some ideas on paper to kick off the conversation through multiple 2-hour sessions. Whatever the approach, always ask your stakeholders what works best for them and their busy schedules.

In the fast-paced world of e-commerce, Agile workshops are a game-changer. They harness the collective expertise of diverse stakeholders, just as cross-team collaboration unites various departments to enhance the Tata CLiQ Palette. By using structured facilitation techniques, we not only gather valuable feedback but also foster a culture of open communication and strategic thinking, essential for adaptive product development. As a software engineer turned MBA student, I see these workshops as a crucible where technical prowess and business acumen merge to spark innovation and drive digital transformation.

Surveys in Agile methodology are akin to the feedback loops that drive continuous improvement in e-commerce platforms like Tata CLiQ. Just as we refine our Java code and APIs to enhance user experience, clear survey questions refine stakeholder feedback, which is crucial for product development. This feedback, gathered across teams, fuels strategic thinking and adaptation, ensuring that every iteration of the product is closer to what customers and partners need. As someone who thrives on assisting others and cross-team collaboration, I see surveys as a strategic tool for aligning diverse perspectives and driving innovation.

When creating surveys for a large number stakeholders, ensure you prototype (or pilot) the survey with a small number of people first. This is to ensure the survey works as expected and more importantly that you are asking the right questions.

To gather stakeholder feedback in Agile projects, I organize focus groups for collaborative input and disseminate targeted surveys for specific insights. Automated telemetry can also be useful real-time stakeholder interaction data depending on the project. All feedback is then prioritized and integrated into the backlog for iteration planning.

Slack surveys through workflows are an effective way to gauge insight from stakeholders esp if those stakeholders would like to give feedback anonymously

Feedback provided during Workshop and Demo Surveys need to be incorporated both before and after the final product to be released so that the customers' concerns are addressed. The feedback should be captured or documented (through JIRA, Confluence, MS Excel etc.) and should be included as a user story/requirement in the next Sprints/Releases planned.

I would go by the Agile value - “Individuals and Interactions Over Processes and Tools”. An agenda based review will help bring multiple stakeholders in a common forum and share their feedbacks on improvising the Product. These feedbacks would then be addressed based on their priority.

The best coaching I've received on sprint reviews: Don't call it a demo or treat it like just a demo. It's more than than that. Even when you cannot "demo" working software, there's ample opportunity to present what you were working on, what's coming up, and solicit feedback on all of it. Don't cancel your sprint reviews because "we have nothing to demo", use it as another opportunity to be transparent about your work and keep your stakeholders engaged.

Unpopular opinion: closed ended questions have their time and place too! Your reviews will be more successful with clear target outcomes. Open ended questions are great for brainstorming and gathering requirements in the beginning of a project. However, open ended feedback during an ongoing project can be challenging to facilitate and lead to the loudest voices derailing your ability to move forward. Lead your on going reviews with close-ended questions that facilitate reaching your target decision by the end of the meeting. Consider polls or surveys when only a Yes or No is needed, or read receipts to confirm information has been received, in place of a meeting.

Absolutely. And to add to that, while it's crucial to have regular review meetings to gather feedback, it's equally important to ensure that these sessions are efficient and to the point. As a Scrum team, we need to understand that the feedback received during reviews should also be considered during our retrospective sessions. This means that we not only evaluate the product but also reflect on our review process and how we can improve it moving forward. This holistic approach allows us to continuously enhance both our product and our team's effectiveness.

Define criteria for evaluating stakeholder engagement, such as communication effectiveness, satisfaction levels, and alignment with organizational goals. Analyze the collected data to identify trends, patterns, and areas for improvement in stakeholder relationships and engagement strategies that’s for analyzed data. Additional to Develop action plans to address identified areas for improvement, including strategies for enhancing communication, building trust, and addressing stakeholder needs.

When collecting feedback from multiple stakeholders in Agile projects, it's important to figure out what information we need and how to get it. For example, we can use tools to analyse usage data, user metrics and other relevant analytics to understand how stakeholders are interacting with our product and see where we can make it better. Also, continuous feedback channels/process help us to mitigate any problem in initial stage of development process. This can be through emails, slack channels, feedback forms, customer support, workshops, focus groups, review meetings, or just informal conversation.

While tools play a crucial role in streamlining feedback collection in Agile projects, it's crucial to remember the Agile Manifesto's guidance on valuing "Individuals and interactions over processes and tools." These tools should serve as enablers for enhancing team and stakeholder interactions, not as barriers. It's the quality of these interactions, fostered through effective use of technology, that truly drives Agile success, ensuring that every voice is heard and every insight is valued.

Tools like Jira, Trello, Slack provide platforms for ongoing communication and feedback collection among stakeholders. These tools often feature boards, cards, or channels where stakeholders can post comments, suggestions, or concerns regarding the project. By using such tools, stakeholders can stay informed about project progress, share their perspectives, and collaborate more effectively with the development team.

It is advantageous to identify a tool that can provide you with graphics that can help you visualize the data you are receiving from the surveys and reviews. This can help you understand the demographics and trends in a visual manner.

I always believe feedback and review system improves the overall execution of projects and help us to identify early failure indicators .identifying the right stakeholders is the key and I will conduct workshops for each WBS and attain feedback from relevant stakeholders holders.

Having an open dialog with all members of the project, including product team members, offering all feedback is good, that is both positive and negative. Ensuring a "No blame" culture, provides honesty, which encourages motivation for success to deliver.

Feedback is expected output from Sprint Review. Feedback collected from Stakeholders should be converted as requirements/User stories by Product Owner. This should be used in next Refinement for prioritising and adding to sprints based on the priority. This is one example of continuous improvement and also shows team is open to feedback and adjust their plan. Also it is good practice to keep track of number of feedback which helps team to discuss in Retrospectives and see where they can improve.

Inspect and Adapt is a fundamental principle in Agile frameworks, emphasizing continuous improvement. It involves regularly evaluating processes, products, and team dynamics to identify areas for enhancement. Teams conduct retrospective meetings at the end of each iteration or project phase to reflect on what went well, what didn't, and how to adjust moving forward. By fostering a culture of learning and adaptation, Inspect and Adapt empowers teams to make incremental changes that optimize performance, increase productivity, and deliver higher quality outcomes. This iterative approach drives continuous growth and innovation, ensuring teams remain responsive to evolving requirements and market dynamics.

Being in this virtual space conducting scrums, retrospection .. tools play a major part unlike the traditional way of white board and looking at each team member face to identify the outcome

Once you have obtained feedback from your stakeholders, what you do with that feedback is key. Evaluate the feedback, identify trends it, and isolate outlier feedback for further evaluation. Plan and adjust the project accordingly and communicate and negotiate these adjustments to your stakeholders. Keeping them informed, aligned and engaged maintains trust and goodwill and positions the project for success.

In order to continuously improve your value delivery chain, it is important and critical to have a cadence for shorter feedback loops built in (basics!) - reviews, retrospectives, customer and market feedback, frequent offline conversations and surveys with identified individuals. It is very important to have a prioritised action plan to implement the feedback, measure these, adjust, adapt, pivot! Stakeholders management is a basic requirement of any project management and delivery - that’s given!

I found the "if" in that question very interesting. One more gem from the AI generated question bank. One more gem from the AI generated question bank.

Agile means continuous interaction-collaboration-feedback. So, simple answer is: to imbibe & follow Agile Principles to the core, not just for the sake of it :) . e.g. in Scrum, sprint ceremonies (Review, retro, refinement, planning) are actually to get stakeholders to agree on something, & get their feedback; which can go into backlog. However, as it happens commonly, Agile is not followed 100%, for whatever practical reasons. So we need to explicitly get feedback from stakeholders by means of Workshops, Show & Tell/demos etc. In-Person/virtual F2F are more effective when we plan outcome-based agenda. Also collaboration tools (e.g. Confluence Jira) are useful to allow stakeholders to provide their feedback then & there.

Instead of asking stakeholders to give all of their feedback at once, you can make it much more manageable by scheduling regular opportunities for them to weigh in on how things are going. Depending on the sprint duration, these could be weekly or bi-weekly milestones, or even once a month during sprint retrospective. The idea is to make giving feedback a natural part of the Agile project so that it seems much less daunting.

In my experience, getting and giving feedback is of utmost important and big responsibility. If we intend to get feedback, the objective and scope of feedback gathering should be clearly defined. Once we are clear on which item/artefact/source code/process/people we need feedback, we could then work to identify the tools could be used. Later continuing to analyse and then adapt.