The purpose of this article is to help YOU (fellow business analyst-perfectionist) to pass the CBAP V3 certification exam efficiently without overspending on prep materials. I wish there had been a CURRENT guide available for me when I stormed the CBAP fortress back in April 2017. After completing thorough online research, I found a few useful but outdated articles and other useful but disparate tips for how to pass the exam. But there was no comprehensive guide for passing the CBAP v3 exam on the first try.

Gherkin is a language used to write acceptance tests. BA's use Gherkin to specify how they want the system to behave in certain scenarios...  It’s a simple language. There are 10 key words (e.g. Given, When, Then). Because it’s a simple language, it’s understandable by the business. As well as being understandable by the business, Gherkin can be understood by an automation tool called Cucumber. That means Cucumber can interpret Gherkin and use it to drive automated tests. This links BA requirements to automated tests.

Business analysis is a broad discipline and we have a whole range of tools and techniques at our disposal. We may get involved within projects, but also outside of them. Many BA teams are actively seeking earlier engagement—when we are engaged prior to a project being initiated we can work with our stakeholders to ensure that the problem space is thoroughly understood. We can encourage stakeholders to think about many possible solution options, and can work with them to ensure that the option that is chosen is the best fit and has the best chance of delivering maximum benefit. Early engagement also helps us avoid the 'first solution trap'.

Ground rules are essential for any meeting. It may be what makes the meeting a success or failure. As a Business Analyst we are constantly organizing and facilitating meetings of various sizes to progress through the SDM (System Design Methodology) for a project. It is important that all sponsors and participants of the project understand what to expect from the upcoming meetings to be organized. Ground rules are generally discussed during the kickoff meeting, documented, and then displayed moving forward.

Scope creep (also known as feature creep, requirements creep, featuritis, and creeping featurism), however, refers to the uncontrolled growth of functionality that the team attempts to stuff into an already-full project box. It doesn’t all fit. The continuing churn and expansion of the requirements, coupled with inadequate prioritization, makes it difficult to deliver the most important functionality on schedule. This demand for ever-increasing functionality leads to delays, quality problems, and misdirected energy.  Scope creep is one of the most pervasive challenges of software development.