How do you facilitate and participate in requirements workshops and meetings?

I agree that planning is a must even if you have been facilitating workshops for a while whether it is just a focus group or a more broader group of stakeholders. Even if it is estimated to only take less than an hour, having a firmed out agenda can act as a guide during discussions.

I agree to this, in addition we should plan at our end, who is going to handle what stuff and if in case any questions asked, based on the role who should take them first

Planning ahead is ensuring that you have the right stakeholders (who in my case are my users) in the meeting along with the right members of your teams.

It can be useful to bring system architectures or diagrams when having workshops. For example operational architectures that show how a system operates. This can stimulate thinking, scenarios etc. which in turn can help with requirement elicitation.

Sometimes it can be helpful to remove from the conversation all the constraints that might limit the requirements. (Don’t worry, they’ll still exist!) For example, you could ask the requirements giver to articulate what they envision if there were no budgetary or other limiting constraints. Understanding there are probably no projects without at least one constraint, having a more clear vision of the ideal goals can lead to outcomes more closely aligned to them. The person giving the requirements might be unaware of the technologies and capabilities to achieve what they are looking for. By envisioning the ideal, unfettered by limits, there is greater opportunity for the team to achieve it even within the constraints that exist.

To me asking people what they envisage often leads the discussion into solutioning rather than eliciting the actual requirement or need. By way of example the requirement maybe to travel from point A to B in a safe, economical and efficient matter. Asking people what they envision may lead to solutioning ideas like Bike, Car, Walk etc. I always try to keep requirements and solutioning as too completely separate exercises as often the most optimum solution can not be determined until all the requirements are known. Many BAs try to deliver what the customer wants, whereby I always believe it's better to deliver what the need. Defined Requirements helps ensure that.

Ways to engage participants that have worked well for me in the past include using an "ice breaker" such as asking everyone their dream vacation. Also asking everyone to describe how they're feeling in the form of a weather report can also be helpful to the facilitator to understand the "vibe" of the room. Involving the audience by way of activities and breakout sessions can also help with engagement. We have all been in sessions where the presenter does all the talking. How engaging is that? Any kind of small group activity helps maintain attention of the group and also serves warning that they will not be able to coast through by feigning attention.

In my experience, these three methods are guaranteed to involve everyone: 1. Short interviews - where each person shares their expertise/issue/idea and the others all note down key takeaways 2. Working "alone together" - where people sit down in the same room for 15-20 minutes, work out their suggested solution individually, then present it back to the room 3. Voting - placing real life or digital votes on the issues they consider most pressing or solutions they find best. Heavily inspired by the Google Ventures Design Sprint method and the book Make Time by Jake Knapp and John Zeratsky

The Team and I put up a Confluence Page and we share it with our Stakeholders before the meeting. We make sure that we have a good understanding of the problem and we ask them to comment on the page or add questions. If we have drafts of sequence diagrams we created in Visio or another tool we share those on that page as well. UXD may have some initial wireframes they have created which help to get the discussion going. Most of my stakeholders are remote, so we use whatever internal communication tools we have to prep them for discussions and to allow them to put comments before we start our workshops or meetings. This has worked very well for me these past two years.

Silent stakeholders who won't provide their inputs, no matter how much you try to get them involved - is something to be aware of. This could be because either they are new, or you are new to them. To solve such situations, I usually catch-up with them casually but professionally, try and understand what their day work looks like, talk about any business related topic which is of their interest. This conversation plays as an ice-breaker and person starts being an active participant in meetings.

The idea to share prepared materials with stakeholders strikes a chord with me. In our team we do the same, with slight difference: we place materials (models, prototypes) and main ideas in letters. The speed of development is quite high, thus our client is not ready to read the whole specification. We incorporate voting for ideas sporadically as well. And I guess the most effective way is to ask the exact stakeholder by name.

A group activity such as Event Storming, (www.eventstorming.com) is a good way to engage all participants, and also help to sequence the steps of a process or activity, which naturally will elicit requirements.

In Agile teams, we also prioritize requirements based on the dev efforts required to put in, in one sprint. If the efforts are calculated to go beyond one sprint, we break the user story further in smaller, deliverable and testable requirements and prioritize them. This is a team effort.

Similar to my comment earlier, during this exercise, I often ask the participants. Does this requirement help us move towards the overall goal/objective of the project. I find this exercise a great technique to eliminate a lot of 'gold plating' style requirements. To me it is only a 'must have requirement' if the overall goal cannot be achieved without it.

Thankfully with agile, requirements gathering can be a iterative process. Value maximization can be done iteratively at every cycle. Based on feedbacks the process can be refined and newer requirements can be added. In practice this is what works

I would say that the most significant part that is missing is to state the overall objective/goal of the Project. I often also put it on the wall or virtual chalkboard. I ask participants to view everything from the lense of how will each requirement move us towards delivering the overall objective of the project. In doing so I find the group remains focused and it is easier to bring the elicitation activities back on track if they do lose focus. Thinking big picture typically leads to higher quality requirements being elicited and minimizes the possibility of too many 'nice to have' requirements being stated.