In our last blog entry, we gave some suggestions of how the agile Business Analyst should lay the groundwork prior to gathering business requirements. In this entry, we will give some tips for the agile BA covering the next couple of main project stages.

• Gathering Business Requirements
     • During your first meeting with business users, gather the High-Level Requirements.
     • Always keep your discussions within scope of the project.
     • If any requirements are out of scope, document them for future enhancements.
     • Diligent users seeking to do their jobs right typically want everything. But remember not all the requirements are critical to business – some could be just ‘nice to have.’ Negotiate with business users and other stakeholders to identify the requirements that will add the most value to the business.
     • If you receive conflicting requirements from different business users, call a meeting to address the gaps. Get the users to justify and prioritize the requirements based on importance and criticality to business.
     • Never offer technical solutions for current issues on the spot, but rather document all issues and take them to your technical team for discussion. Then come up with solutions that can be shared with the business users.
     • Document all the points and send them to the business users after the meeting. This will ensure that the points are correctly conceived, and, if any are wrongly captured, that the business users will have the opportunity to correct them.

• Leading Joint Application Development (JAD) sessions
     • Realize that it will be next to impossible to get developers and other team members, as well as other stakeholders, together all at once to sit in a room and brainstorm about system design.
     • Be willing and able to play the lead role in administering, managing and facilitating JAD sessions.

• Documenting the Business Requirements
     • When you develop the business requirements document, spell out the details clearly, without any ambiguity or vague points. Use simple words to describe the requirements.
     • Present the requirements with diagrams, flow charts or pictures. Remember, “a picture is worth 1,000 words!”
     • For effectiveness, use Use Case or UML diagrams to present the details.
     • Use MS Visio to present the workflow models or business processes clearly.
     • Provide both ‘AS-IS’ and ‘TO-BE’ models, so that business users can compare and understand the differences.

In our next blog entry, we will wrap up this series with some tips for the agile Business Analyst during the stages that follow the documentation of business requirements.