Skip to main content

Author: Deborah McLaughlin

Do You Hear What I Hear?

Imagine a team of business analysts gathered in the conference room discussing new features with stakeholders.

After the meeting they compare notes and are surprised at the differences in the information gathered.

Each business analyst had a list of questions for the stakeholders. They were all very similar:

What are you trying to achieve with the functionality?
How will it support your current business processes?
How often do you perform this task?
Do you receive inputs from another person or document?
What is done with the completed output?
How do you accomplish this today?

The client answered all the questions and some viable solutions were discussed for the requirement. The assigned business analyst had an in-depth discussion about what would work for the stakeholders and what wouldn’t. Questions were asked and answered about priority, what were their must haves and what should be delivered first. This process was repeated several times as each business analyst presented their initial investigation results. The stakeholders provided a wealth of information.

Business Problem

The stakeholders described their issues and gave specific examples. It wasn’t entirely new information. It may have been the reason the meeting was called. They reiterated the business problem and scenarios. They stated what they need to be able to do and why.

Current Work Flow

They went into detail about their current process. They begin with this piece of data. They review the files and documents and look for specific information. Key figures are located, calculated and input into the system. Reports are generated, analysis begins, and proposals are made.


When asked how often these tasks were performed, we found out that it was a good portion of their week. This was one of their major job functions and they might start this process in the morning, stop for a meeting or lunch and then resume. We gained more insight into the need to work two projects at the same time.


The stakeholders told us what about the current process was frustrating and what changes could make it better. Some were large requests, others were very small changes. Any of them would make a difference in their daily work lives. Some would make them happier than others.

Comparing Notes

Everyone in the room heard this information, but all of it was not reflected in their meeting notes. The content collected ranged from a few lines to a few paragraphs per person. Why is that? There could be assorted reasons including:


The focus is on answers to specific questions

If you have completed some initial investigation, you have a list of questions for the stakeholders that you need answers to. You may be listening for these answers and filtering out the rest. It’s not always easy to switch between the question you asked and a new topic or question that your stakeholder raises.

Take a deep breath and try pausing the conversation to “jot this down”. You can also ask teammate to act a scribe during your discussion until you become more experienced.

The statement was obvious or easy to remember

Most people don’t write down statements that they have heard before. It may seem like a waste of time or duplication of effort. In reality, you need to know what is important to each stakeholder and what issues are important to multiple stakeholders. This will help in accessing priority.

Everyone thinks they have a good memory until they don’t. Writing (hand writing on paper) things down has been proven to be more effective at helping you remember than typing notes on your laptop. Maintaining eye contact is easier when you are not staring at your screen.

Write the speakers initials by what was said. When you review your notes, you will know who was most passionate about certain functionality.

It didn’t seem important at the time

You won’t always know what is important when you hear it. Later in the investigation, it might provide insight or clarity when trying to convey the stakeholders must haves to members of your development team.

It may seem impossible to capture everything that is said, but if you just jot down a few words it will help jog your memory.

The conversation was about a requirement assigned to someone else

This one is less obvious, and not many people do this. You should be taking notes during the entire meeting, not just when you are looking for answers.

Being part of a team means that you should be aware of what your teammates are working on. Taking notes while they are leading the discussion will not only help you retain this information but will be beneficial to them when you share notes with them afterwards.

Up your game

Being a good listener is one of the most important skills to a successful career as a Business Analyst. To be able to retrieve the information that you heard quickly and with accuracy is just as important. Writing down everything that has been said, even if you’ve heard it before, can give you a head start on your business problem and user story. It is more compelling when explained in the stakeholder’s words.

Consider ways you can improve your listening and note taking skills. Try it all your meetings, not just your requirements gathering. See what a difference it makes in your ability to recall vital facts and in your productivity. If you are looking to move from an individual contributor to a team lead or manager, this is an invaluable skill to hone. Demonstrating leadership skills is the first step to receiving additional responsibility and promotion.

The Elaboration Formula

You have finished your requirements gathering and now need to convey your vision to the software development team, where do you begin?

I start with the following formula: View, Create, Edit, Delete, and Print. These are the five primary ways a user will interact with your software application.

Although this conversation is directed at the new software business analyst, even those with experience can occasionally face a bit of writer’s block. If you get the basic foundation laid then you can concentrate on the complexities of your feature.


Is this totally new or a modification to existing functionality? Can it be seen in your application today? What needs to be added here? An entire page, grid, report or just a field? How does the user navigate to the functionality? Do we need a new menu option or a button to launch a new page? Laying the framework for the new functionality is often the hardest thing to conceptualize. Take a step back and put yourself in the user’s shoes.


Is the user going to create or add a new record? What fields are needed? Which ones are required, and which are optional? What happens when they save the results?


Can the user edit or modify an existing record? How do they tell the application that they want to make a change? Are the fields always enabled or do they have to select an option to edit?


Is the user allowed to delete a record or must it be marked as inactive? Is the record archived or does it persist in the database?


Does the user need to print the results or just view them on the screen? How should the initial display be sorted? Do they need to option to filter the results in some way? Are we printing as a PDF, to Word or both? Is there a business reason to export to Excel?

If your feature is to create a new report, you may be looking at additional inputs to pull different subsets of data. Titles, dates, page numbers, headers and footers will come into play. How are sections grouped and totals displayed?

Other Considerations

What else do we need to consider? Permissions is the first one that comes to mind. Can any user complete all these actions? Are only certain users allowed to delete? Does your application have an existing permission module that needs to be modified?

What are the business rules or constraints that need to be implemented? Do we warn the user or block them from certain actions? Do your data entry fields have character limits or do they need to be unique?

Does this functionality impact or integrate with other areas of the application? If new fields are being added, do they also need to be added to existing reports or dashboards? If you are working with a robust or enterprise application, it may be handy to have a checklist of the potential areas of impact.


What does it look like?

Some teams may include a UX designer, but more often a business analyst must create a initial mock-up of the new functionality. This may be a drawing on a whiteboard with input from your team or be created digitally so that it can be sent to stakeholders for review. A picture says a thousand words can quickly convey your concept and generate insightful questions.

Putting it to paper

How you document this for your team depends on your current organization and methodology they use. A traditional functional spec or design document will spell out the solution in detail and typically includes a mock-up of the new screen/grid/fields/report. A use case document will detail the interaction between the software and the user. User Acceptance Criteria will speak to the basic requirements that the user needs to accomplish for the user story to be marked as DONE. They are all conveying the same vison in a different format.

  • Design: Add the new functionality button in the application location.
  • Use Case: The system displays the new functionality button in the application location. The user invokes the new functionality button. The system displays the new functionality page/grid/report.
  • User Acceptance Criteria: The user can view the functionality name in the application location.

Many organizations will have a combination of documents that are needed to get a requirement from concept to development complete. Elaboration is just one step in the development process.

Don’t reinvent the wheel

Unlike writing your college term paper, elaborating requirements and writing user stories is not graded on originality. It is actually more productive to borrow or re-use sections from similar functionality documented in a previous sprint or release. Your team will be more comfortable with the steps that were used before and you have a reference to ensure that all areas are covered. Review the defects, linked stories and documents to see if anything was overlooked in the previous endeavor that should be included upfront this time.

Create your own Formula

This formula might not be the best for your specific project, but it might help you create one that is. What steps come to mind when you receive a new feature? Is there a mental checklist that you follow or one at the back of your documentation template that covers impacted areas? Is there someone on your team that has a knack for taking a new feature and running with it? They probably have a formula in their head that they are unconsciously working through. Find your formula, rinse and repeat. Build better software.

Breaking the Barriers to Certification

Have you debated getting a certification but run into obstacles? Did you find that you didn’t have enough work experience or the money to pay for the education hours and suddenly lost your motivation?

Perhaps you didn’t even understand the options available. We’ve all faced barriers reaching our goals. Now is the time to take a second look at your options.

I don’t want to discuss which certification(s) are best for you personally. That is a decision you should make for your yourself. Do some research. Try to answer the following questions:

  • What is your long-term career goal? Search for current job postings that reflect that role.
  • What certifications are required or suggested for the role?
  • What certifications are required for other roles in your current organization? Which do they value?
  • What certifications do your co-workers or professional colleagues have?
  • What is the market for a specific certification or skill? Search for that word in your favorite job board and note the count of postings that come up.

Work Experience

Lack of work experience may be the most difficult barrier to overcome. If you are new to the role, you won’t have the five years needed for some certifications. Don’t get discouraged. Add it to your professional bucket list and find one that you can you can achieve in the next twelve to eighteen months. Keep a running spreadsheet of your project descriptions, start and end dates and what activities you performed. It will expedite the application process in the future.


Cost is often a barrier. Typically, the fee for the exam is less than the cost of the education hours or boot camp for the exam. Read the application instructions carefully. Does it require specific in person training? Is there an online or weekend class available so you don’t have to miss work? Does the professional organization have a local chapter training available at a discounted rate to members? Can you utilize free or low-cost webinars from the professional organization or other vendors to fulfill the requirements? Have you had recent training that will meet the qualifications? Do you need a boot camp, or will a study guide and an exam simulator suffice? Reach out to colleagues who possess the certification. Ask them what resources worked best for them.

Determine all the costs: application fees, membership, exam fees, and education hours. Also consider the cost of renewal and continuing education hours that are required. Consider the cost of maintaining multiple certifications.

Check with your current employer to see if tuition assistance is available. They may pay for all, part or none. If you are unemployed, check with the professional organizations to see if discounted rates may be available.

If are self-employed or your employer can not reimburse you does not mean it is not worth pursuing. Review your other payment options or ways to save for the required amount. Remember, this is an investment in your education and career.

What are the options?

The following list is not all inclusive but may provide some new options you haven’t considered. Those with the least amount of work experience are listed first. Requirements are summarized, so read the current eligibility requirements on the organization website for specific details. Additional work experience may be required if you don’t have a bachelor’s degree. Work Experience and Education hours may need to be within recent years, so take note of those dates. Please confirm current costs with the organization as there may be regional differences.

PSM Professional Scrum Master

  • Organization:
  • Work Experience: None Required
  • Education hours: None Required
  • Renewal: No renewal required
  • Note: Training is available but not required. If you have a good understanding of the Scrum Guide and an elevated level of knowledge gained from direct experience or other training, you may feel comfortable taking the assessment. Open Assessments are available to help you gage your readiness.

PSPO Professional Scrum Product Owner

  • Organization:
  • Work Experience: None Required
  • Education hours: None Required
  • Renewal: No renewal required
  • Note: Training is available but not required. If you have an elevated level of knowledge of the Product Owner Role gained from direct experience or other training, you may feel comfortable taking the assessment. Open Assessments are available to help you gage your readiness.

ECBA Entry Certificate in Business Analysis (IIBA Level 1)

  • Organization: International Institute of Business Analysis (IIBA)
  • Work Experience: None required
  • Education hours: 21 hours, IIBA webinars eligible
  • Renewal: No renewal required


CSM Certified ScrumMaster

  • Organization: Scrum Alliance
  • Work Experience: None Required
  • Education hours: 16 hours, specific in person training
  • Renewal: Fee

CSPO Certified Scrum Product Owner

  • Organization: Scrum Alliance
  • Work Experience: None Required
  • Education hours: 16 hours, specific in person training
  • Renewal: Fee

PMI-ACP PMI Agile Certified Practitioner

  • Organization: Project Management Institute (PMI)
  • Work Experience:2000 general project experience working on teams plus 1500 hours working on Agile project teams or with Agile methodologies
  • Education hours: 21 contact hours of training in Agile practices
  • Renewal: Fee plus 30 hours (PDUs) every 3-year cycle

CCBA Certification of Competency in Business Analysis (IIBA Level 2)

  • Organization: International Institute of Business Analysis (IIBA)
  • Work Experience: 3750 hours of Business Analysis
  • Education hours: 21 hours of education in Business Analysis
  • Renewal: Fee plus 60 hours (CDUs) every 3-year cycle

CBAP Certified Business Analysis Professional (IIBA Level 3)

  • Organization: International Institute of Business Analysis (IIBA)
  • Work Experience: 7500 hours of Business Analysis
  • Education hours: 35 hours of education in Business Analysis
  • Renewal: Fee plus 60 hours (CDUs) every 3-year cycle

PMI-PBA PMI Professional in Business Analysis

  • Organization: Organization: Project Management Institute (PMI)
  • Work Experience: 4500 hours of Business Analysis experience, including 2000 hours working on project teams
  • Education hours: 35 hours of education in Business Analysis
  • Renewal: Fee plus 60 hours (PDUs) every 3-year cycle

PMP Project Management Professional

  • Organization: Organization: Project Management Institute (PMI)
  • Work Experience: 4500 hours Leading and Directing Projects
  • Education hours: 35 hours of Project Management education
  • Renewal: Fee plus 60 hours (PDUs) every 3-year cycle

These are just a few of the options available for your consideration. Take a closer look and you may find that a certification is in your future!

Onboarding a New Business Analyst

It’s always exciting to add a new member to your team, but it can be a bit stressful.

Some advanced planning can make the transition easier and ensure that your new Business Analyst has everything needed to be successful.

Every new employee comes with a unique set of experiences, so it is necessary to assess their current skills as compared to the responsibilities of the new position. Some of this assessment was done at a high-level in the interview process, but now the details need to be analyzed. Consider the following criteria:

  1. BA Skills: How many years of business analysis skills does the team member have. If they are moving from another team within the company, they may need more basic training in Business Analysis techniques.
  2. Industry Knowledge: Has the BA worked in your industry before. There may be specific terms, acronyms and business concepts that they need to know.
  3. Technical Skills: Determine what tools are commonly used by your team that require training. Examples include: Team Foundation Server, Jira, Confluence, SharePoint, video and screen capture tools.
  4. Soft Skills: This may not be immediately apparent when evaluating a new team member but there are several that all Business Analyst need in their toolkit.
  5. Software Methodology: Is your project using a traditional waterfall or Agile methodology. Does your team need to understand the Software Development Life Cycle (SDLC), Dynamic Systems Development Model (DSDM) or Scrum?
  6. Internal Processes: These are different for each organization and department and will need to be included for every new team member.

Once the required knowledge and skills have been identified, we need to look for existing resources available to train new hires. Be creative. Think outside the box but stay within your budget.

  1. Organizational materials: Most companies have some basic training materials. Some departments may have developed some on their own. Ask if they will share and see if all or portions are applicable.
  2. Team Handbook: Providing the new BA with a handbook or Quick Reference Guide of internal processes can provide a high-level view of the new role. When they ask questions that are not answered in the handbook, the resulting revisions will help the next new team member. If it doesn’t already exist, now is the perfect time to build one. Start at the beginning, what does a BA do every day, every week, every iteration, every release.
  3. One on One training: Internal processes are typically trained by another person on the team. Shadowing an existing BA as they take a feature or requirement from beginning to end is quite helpful.
  4. Internal training classes: If you company provides software internally or externally, they may also have classes or computer-based training available for the application.
  5. Reference Books: Does your team have a library or book shelf of technical reference books? These are very useful for information on BA techniques, technical skills and software methodology. Make it a habit to browse your favorite book seller every few months for new titles.
  6. Learning Management Systems: Some organizations subscribe to a Learning Management System (LMS). Scour the catalog for topics that have been identified.
  7. Blogs, articles and webinars: Always look to BA Times for webinars and articles that meet your training needs. In addition to tasking them to create an account, provide a list of links to the webinars and articles to view.
  8. Third party vendors: Determine if there are in person classes from a third-party vendor in your area for some hands-on training.


Creating an onboarding plan will help clarify expectations and provide some short-term goals for the new addition to your team. Some suggestions are:

  1. Checklist: A standard checklist for your team can be created that is reusable and modified based on the individual needs. This keeps the things from falling thru the cracks during that hectic first few days.
  2. One-month plan: Define the most important training tasks to be completed in the first month.
  3. Track tasks: How does your team track tasks? Outlook, Excel, SharePoint, Kanban, Jira or Team Foundation Server? You may consider creating tasks for the training to be completed.
  4. 90-day plan: What are the longer-term goals. What activities should the BA be proficient in to be considered a contributing member of the team.

The onboarding experience creates a lasting impression that can determine the new employee’s success and happiness on your team. Conversations about goals and expectations should occur weekly in addition to explaining the “why” behind the processes. Handbooks and training materials should be updated and relevant. Reasonable time should be provided for the team member to complete necessary training. Don’t overwhelm your new employee in the first few weeks. Remember, everyone is unique and there is not a one-size fits all approach.