“We will start by reviewing and approving last meeting’s minutes”… “This is not what I have captured in the notes from two months ago”… “If you compare our notes from meetings #4, 5 and 7, you will conclude that…” “In the recording from session #16 you said…”
With people joining or skipping meetings, going on vacations and coming back, new team members joining partway through and the requirements and scope changing, the value of aging meeting notes diminishes quickly:
- Some points made during a meeting may be a repetition of what was previously said, a variation of the same point, or a contradiction
- Something that team believed was true a month ago may be proven incorrect through data analysis
- An off-the-wall or ironic comment may be captured at the face value
- A misleading point made by a particularly loud personality may be corrected offline later
Next thing you know, the analyst is scheduling a meeting “to review the notes” where the group will be walked through the points and will waste their time making corrections, changes, and comments like “Have we not discussed this before?”, “This is not what we said”, “This was already captured in document or backlog” or “This is a duplication”.
Dear Business Analyst:
The role of the analyst is not the same as a committee secretary or a court stenographer. Taking the notes at requirements meetings, solution workshops or backlog reviews and adding them on to a long document or uploading to a “Meeting Notes” SharePoint folder does not constitute analysis.
Any chronological aggregation of notes quickly becomes outdated, and maintaining it may be a resource-gobbler. It should be kept to the level established by the governance or audit requirements.
Instead, each meeting, discussion or analysis activity should contribute to the requirements repository, whether you use a backlog, a requirements management tool or a document. At any time, there should be one single shared most recent version of business requirements. Each new discussion should result in this repository being updated or confirmed.
The overall goal must be an agreement on the updates to that single current version of requirements, meeting notes notwithstanding.
Copiously writing down everything that is being said for fear that you will miss something may cause just that – make you miss something important. Groups of people have little patience for waiting while you are typing – they might just continue the discussion among themselves.
The more you can listen and absorb, and capture later, the more you can truly facilitate a productive discussion. The added value of the analyst is to actually analyze what is being said (and perhaps not being said), and organize and aggregate it into a representation of the business problem and a potential solution – e.g. into business requirements.
If you do not analyze what you hear, you are not practicing business analysis.
More posts in the Business Analysis Pitfalls category.
Find all Business Analysis Pitfalls posters in the Business Analyst Mindset Digital Toolkit.
Contact Yulia for individual coaching, speaking, or helping your organization mature its business analysis function.
This is so true. One part of Agile that I love is the fact that the requirements are more malleable. Up until a story is pulled into a sprint there can be discussion that might change it considerably from the original story or thought, and it is expected! Nothing stays the same and Agile is fluid enough to allow the process to develop as more is learned. I also like that no one points back at a requirement and says, “That wasn’t in the requirement”, when something is overlooked (well, they shouldn’t do that, at least). The team works together to come up with acceptance criteria and consider all the points that an enhancement or feature will touch so they can all be tested. We sometimes don’t think of everything until UAT when a user notices it. Even though it usually involves creating a new story, no one is pointing fingers at what was documented and placing blame. I love your book and your blog and often share your posts with my fellow BA coworkers. 🙂 Looking forward to checking out your new channel on YouTube as well!
Hi Tammy, thank you for this wonderful and thoughtful comment. You’ve articulated so well that there is a much better way to validate requirements than trying a “big bang” approach. Your team is lucky to have you – you use a sensible mindset to manage user stories. Thanks for reading and sharing my posts. So grateful to have connected with you. Best wishes, Yulia