BPM Library

The role of the BA facilitator is to guide activities on developing both the vision and software solution. The key word here is guide.

The BA facilitator role provides process to group settings and avoids participating in content. Typically, the BA facilitator role serves as the liaison between stakeholders, and the stakeholders and software development team respectively. As the liaison, the BA facilitator role uses various techniques and emotional intelligence skills to assist project sponsors and/or team leaders in accomplishing group meeting goals:

• Facilitation Techniques for identifying solution features

o Creating a Solution Vision and Scope

• Brainstorming – discussing of ideas
• Brainwriting – submitting written ideas for discussion

o Eliciting Features and Associated Business Rules

• Focus Group Meetings – soliciting opinions
• Joint Application Design – resolving conflicts

o Analyzing Features – Assumptions, Constraints, Risks, and Issues

• Root Cause – 5 whys, Ishikawa Diagrams
• Force-Field – listing negative and positive influences
• As-Is and To-Be Gap

o Making Decisions on Features and Priorities

• Multi-voting – subjective paring down a long feature list
• Criteria-Based Grid – weighting feature value criteria
• Impact/Effort Grid – comparing feature benefits versus effort

• Emotional Intelligence Skills for interfacing with stakeholders

o Active Listening and Paraphrasing
o Generating Participation
o Neutrality – focus on meeting process instead of solution content
o Questioning – seeking answers rather than posing solutions
o Maintaining Focus – use a parking lot and issue log for off agenda topics
o Obtaining Stakeholder Feedback
o Summarizing and Synthesizing Ideas
o Conflict Intervention



From The Need for the Business Analyst Facilitator Role
in an Agile Software Development Team
By Mark Monteleone, CBAP

The requirements gathering is a major part of the Business Analyst responsibilities.
As a first step of every project the requirements are crucial for the next phases of the project. They have to be complete and useful.

Here is a list of the characteristics of the requirements

• Cohesive - The requirement addresses one and only one thing.

• Complete - The requirement is fully stated in one place with no missing information.

• Consistent - The requirement does not contradict any other requirement and is fully consistent with all authoritative external documentation.

• Correct - The requirement meets all or part of a business need as authoritatively stated by stakeholders.

• Current - The requirement has not been made obsolete by the passage of time.

• Externally Observable - The requirement specifies a characteristic of the product that is externally observable or experienced by the user. "Requirements" that specify internal architecture, design, implementation, or testing decisions are properly constraints, and should be clearly articulated in the Constraints section of the Requirements document.

• Feasible - The requirement can be implemented within the constraints of the project.

• Unambiguous - The requirement is concisely stated without recourse to technical jargon, acronyms (unless defined elsewhere in the Requirements document), or other esoteric verbiage. It expresses objective facts, not subjective opinions. It is subject to one and only one interpretation. Vague subjects, adjectives, prepositions, verbs and subjective phrases are avoided. Negative statements and compound statements are prohibited.

• Mandatory - The requirement represents a stakeholder-defined characteristic the absence of which will result in a deficiency that cannot be ameliorated.

• Verifiable - The implementation of the requirement can be determined through one of four possible methods: inspection, analysis, demonstration, or test. The expected methods are usually test or demonstration. The inspection or analysis are done just in special cases.

For more information see here