Requirements workshops are the table stakes of business analysis. This is where we interview groups of stakeholders, gather information, listen to stories, and ask questions. This is where we separate truth from fiction, pain points from root causes, and desired solutions from real business requirements. This is where we validate captured requirements and process flows, review the logic, and check for gaps.
Requirement workshops are (or need to be) thinking meetings.
Over and over, in different companies, on different projects and with a different team set up, I observed the deficiencies of a typical “one-hour meeting”. Most of the time, this is not a suitable duration for a thinking meeting.
Why not? Let’s do some math. Where do 60 minutes usually go?

The first 5-10 minutes are usually spent on waiting for latecomers, meeting rooms that free up late, and web conferencing hiccups.
Another 5 minutes may be spent on the chit-chat, discussing the latest events or someone’s birthday or promotion, or whatever is accepted and expected as small meeting talk in each organization.Shorter 30-minute meetings sometimes skip the chit-chat, and it is a no-no for a 15 -minute stand-ups. However, one hour is perceived as long enough to allow for it, and it might be a good idea for a thinking meeting, to put everyone at ease and let their brains free up some space for new thoughts and flush out the stress from previous activity.
Another fraction of time is then spent to orient the participants towards the real reason for the meeting: recap the agenda and remind everyone where did we leave off the last time. At this point, it is necessary to fill in any memory gaps:
Didn’t we discuss this before?
Why was this a problem?
I thought we already agreed on what comes next. Why are we changing it again?
Did we get an answer to that question that stumped us the last meeting?
Or my absolute favourite: Which project is this?
This re-orientation is especially important in requirements meetings as each one addresses a few pieces in the bigger puzzle. Humans need a big picture reminder to focus better on how each piece fits into the whole.

Depending on the stakeholder team, their depth of involvement and how good a BA is with inter-meeting communication, this recollection step may take from 1 to 10 minutes. Business team members may participate in multiple projects on top of their operational duties and attend numerous meetings per day. The concepts, the processes and the ideas can get mixed up.
It’s in the business analyst’s best interests to have everyone start from the same point in a meeting, and it is also their responsibility to bring everyone to that point.

By the time the group is ready to start actual analysis, you may have lost 15-20 minutes already.
The efficiency of the remaining working minutes will depend on:
- How prepared the business analyst is. Minutes can be lost on waiting for a BA to locate the correct file, email or data, and point to the right place in a process flow where the discussion needs to resume.
- How prepared the team members are. If participants had takeaways from previous meetings, will they present their findings? Provide answers? Will need to show and tell? Do they have everything they need?
If the takeaways were not completed or not shared in advance, more time will be taken up by switching presenters, asking whether everyone can see their screen, and recapping the new information. Alternatively, the group may discover that the person expected to bring new information in did not bring it – too busy, forgot, or misunderstood what was required.
- What activity the group is involved in. Is it brainstorming, discovering process steps, comparing scenarios? Is this a familiar activity that everyone is comfortable with, or someone may have difficulty with the format and the tools?
- How complex is the issue – is the team stumped or does it merely need to work through the steps logically? Is there new quality information to help move analysis along? Is a leap of imagination required? A shift in thinking?
- What tools are going to be used? If a BA is modelling during the meeting, it can help keep the meeting engaging, as long as they have the skills, shortcuts, and the team understands the conventions.
- How lofty is the agenda? If the group is trying to do too much, they may jump from one agenda item to the next without resolving anything and finish not much further along from they started.
- Is there sufficient data, artifacts and materials to resolve conflicts or contradictions? A battle of opinions can eat up a lot of time while having objective facts, data and analytics can support the effective resolution.
- Does the team have an agreed-upon decision-making mechanism? Can important decisions be made within the meeting, or do some decisions need to be parked for further approval, thus delaying the analysis?
In the ideal project team, a decision-maker, whether you call them a product owner, product manager, business lead or business sponsor, should be present at the meetings and do their part to facilitate decision-making.
The remaining working minutes will drain away very quickly in a meeting that requires thinking – even with the best preparation. Without it, the meeting will not achieve much.
We will not count the last 5 minutes of the meeting when most people will already be mentally switching to the next activity, anticipating a snack or finishing their day. And you need a couple of minutes in the end to recap the results and next steps.
The bottom line is, 35-40 working minutes may be enough for a gathering where the main goal is to share previously prepared information with the group.
It may be enough to analyze one or two remaining scenarios if there are no major issues.
But most of the time, it is not enough to get deep into analysis, especially into root cause analysis. It takes a while to get everyone’s brain working on the problem, and just as the creating juices start flowing, the energy in the room is at its highest, and you can finally see the group focused on the task at hand, the meeting has to end.
What’s the solution?
One well-run two-hour thinking meeting is much more efficient than two one-hour meetings.

Advantages of a longer thinking meeting:
- Save time on the warm-up and getting the group up to speed.
- Take advantage of the longer “full throttle thinking” period when the group is at optimal performance for problem-solving.
- Get deep into difficult problems that you’ve failed to figure out in shorter meetings.
- Sufficient time to use more than one way of sharing information leading to better validation and shared understanding, e.g. discuss + draw diagrams + capture key rules + role play + mock-up or storyboard.
- Higher commitment levels: a single two-hour meeting will be perceived as more important and less likely to be missed by key stakeholders than one of the two subsequent one-hour meetings.
- The meeting is perceived as (and usually is) less bureaucratic.
- Often easier for the busiest stakeholders to accommodate (e.g. rearrange a schedule for one day only instead of two days).
- Time to introduce motivating elements such as snacks, jokes or brief interludes to encourage collaboration.
- More time to capture main points of the discussion, reduce the documentation burden and future misunderstandings.
- If organized well, can become a cherished two-hour oasis of creative work for the participants.
The main disadvantage, of course, is that the corporate world is accustomed to a one-hour meeting cadence, and two hours sounds like a big ask. It is up to a business analyst – ideally with support from the project manager – to persuade that it makes sense. Use the arguments laid out in this article, add your own, and experiment to work out the duration that gives you the most analysis efficiency.
How do you recognize meeting topics that require a longer duration?
Think about it in terms of deep thinking vs shallow thinking.
If the meeting does not require intense thinking – such as presenting information, status updates, planning, or celebrating, then a short meeting is sufficient.
If the main goal is to solve a problem, analyze a difficult issue or assess a set of requirements for completeness, validity and logical inconsistencies, then you need to engineer a meeting where a higher portion of time can be devoted to focused thinking and analysis.