Skip to main content

Tag: Agile

BATimes_Dec15_2022

Good at Drawing or Good at Visualizing – There is a Difference!

Written by Line Karkov on . Posted in Articles.

I often use simple diagrams and icons enhanced with text done with pen on paper instead of long presentations. It is a skill that I have practiced over some years now. Sometimes, colleagues tell me that I am good at drawing, but the fact is that I am not good at drawing. I am good at visualizing, and I am also fairly good at listening. This article is about what I mean by that.

Let me demonstrate with an example. The two drawings below are similar to two illustrations I did earlier this year. They are translated into English and made generic in content to make them understandable without knowledge of our business. I have also left out the detailed text that is included on the originals. Not only do they make no sense out context, but it also emphasizes the simplicity of the actual drawing.

 

Advertisement

 

Earlier this year, my manager asked me to do a drawing of our IT strategy. We work in an organization that is in the non-profit sector and we are not an IT organization. Out of 200 employees, 10 of us work with IT – all development is outsourced. The audience of this strategy was a management team where only my manager has a background as an IT professional. So, we needed to make it visual and easy to relate to. Part of our strategy is to rely as much as possible on software-as-a-service, so that we always have evergreen applications, and we don’t need to take care of upgrades etc. ourselves. “Evergreen” is a great image that is easy to understand and also easy to draw. I decided to include that in the visualization. When we talk about enterprise architecture and strategy, it is common to perform gap analysis and plan for closing that gap. A gap is also easy to draw. So, my first draft looked like the drawing below, with some text added on each side to about the goals of the initiatives and the applications that were impacted.

 

My manager presented this to our CEO, who said: “It’s a pit that we are filling with dirt?”. Having primarily worked in IT organizations, I have never questioned this metaphor of the gap. But he was right. When you think about it, it isn’t really that inspiring to just fill a gap. Ok, we needed something else. I have earlier used a Greek temple to illustrate IT architecture strategy. I like the comparison of solid, sustainable IT architecture with classic architecture with its timeless qualities. My first thought was an aqueduct transporting water to our evergreen application landscape. But I liked the idea of something that could transport our organization and was afraid that the aqueduct was too abstract. So, I decided to illustrate it with a bridge inspired by Roman architecture. The pillars of the bridge are made out of the initiatives on our roadmap. One pillar is made up of the initiatives for improving our services, and the other the initiatives for improving administration. Together, they will enable the organization to walk across from a withered to an evergreen field. That resulted in this drawing (again, with additional text next to the side of the pillars related to the goals):

This was the drawing that was presented to the management and later to the board. I think it is a better drawing than the first one and that is not because it technically is a better drawing than the first one. But because the metaphor was more fit for purpose. This is what I mean, when I say that my strength is not drawing, but visualizing. The ideas for how to visualize various topics comes from listening to how people talk about their work, the topic for the visualization, and the feedback that I get. You might notice that the first drawing includes seven initiatives, the second only six. This is an example of how the structure can sometimes dictate content. We had to prioritize and leave an initiative out that is more related to infrastructure but was included for its significant impact on business users.

Below is a drawing that my son Thorbjørn did recently. He is 10 years old.

I think we can all agree that he technically is better at drawing, than I am. Look at the facial expressions and walking legs as examples.  So, just to emphasize the point even further: You do not need to draw as well as a 10-year-old to apply your drawing skills at work. You probably do to be a professional graphical facilitator, but that’s a completely different story.

As business analysts, many of us are well trained at visualizing. We use this skill when we do process maps, application landscapes, mockups, conceptual models or logical data models. Use this to your advantage, and you will find, that it is possible to learn the drawing skills that enable you to apply visual thinking in your business analysis practice.

Curious about visual thinking, but don’t know where to start? I wrote these articles last year, which might give you some inspiration:
Start your visual facilitation journey with letters. – Business Analyst Articles, Webinars, Templates, Jobs (batimes.com)
The icon library: My favorite analogue tool – Business Analyst Articles, Webinars, Templates, Jobs (batimes.com)
BATimes_Nov23_2022

Avoid Illusory Constraints And Incentives

Written by Adrian Reed on . Posted in Articles.

If you were learning to drive in the UK, chances are you’d get in touch with a driving instructor. Over here, many of the driving schools they work for have company names starting with the number 1 (often ‘1st CompanyName Driving School’).  I suppose if I were a driving instructor my default company name would be “1st Reed” or something similar.

It might seem curious as to why there are so many driving schools with “1st” in their company names. We might assume it’s a signal that people who learn with them pass their driving test first time… but I suspect there’s another legacy reason, which goes back twenty years or more.  You see, when I learned to drive, you didn’t Google a driving instructor, you used the Yellow Pages.

 

For anyone unfamiliar with the Yellow Pages, it used to be a thick local telephone directory of different companies. It probably still exists, but twenty years ago it was an essential reference for every household and could usually be found close to the (corded) landline telephone.  It was printed on thin yellow paper, and had thousands and thousands of companies listed.

You’d search for a category (‘driving instructor’) and then (with the exception of paid ads) the companies were generally listed in alphabetical order.  And company names starting with numbers were given preference, so a company named “1st Aardvark Driving School” would be listed above “Aardvark Driving School”… hence the incentive to start a company name with the phrase “1st…”.

 

Advertisement

 

The Constraints and Incentives Of Yesterday Might Be Irrelevant Today

Today, I would guess that very few people search for a driving school using a paper telephone directory, so this necessity to preface a company name with ‘1st’ is no longer valid.  Not only this, it could actually hinder findability…. Imagine if you heard somebody say their company name was “First Reed”.  Would the URL be 1stReed.com, FirstReed.com, First-Reed.com, or something else?  What keyword would you type into Google to search for them?

I wonder if issues of ‘digital findability’ might also start to affect musicians. With more and more people using voice-activated assistants, bands might get more airplay if they have a band name and a song name that is “voice assistant friendly”.  Don’t believe me? Try to get an AI assistant to find music by 90s band Campag Velocet and you’ll likely see the problem.

The point here is that constraints and incentives of yesterday (“We must start our company name with ‘1st’” or “Unusual band names sell records!”) might actually be disadvantages today.  The incentives and constraints have changed, and those that recognize that can use it to their advantage.

 

What This Means For BAs: The Importance of Healthy Challenge

This is where good business analysis helps.  It often feels that there is a human tendency to revert-to-norm and to “do what we’ve always done”.  In our world as BAs, this might relate to the way work is undertaken, the way a process works, or the way that technology is used.

In these situations there is a huge opportunity to tactfully challenge: to ask does it still need to be that way? And also ask what are the implications if it is implemented that way? Are we ‘baking in’ a constraint that is no longer relevant?

This starts by identifying those tacit assumptions and constraints and seeing whether they are really still valid. Techniques such as ‘five whys’, the brown cow model, or just informally asking questions with curiosity and listening deeply to the response can help a great deal.

Whichever techniques we use, having the confidence to build rapport and tactfully challenge accepted practices is key. Sometimes there might be a valid reason for the status quo… but if there isn’t, we might be able to help co-create a better way with our stakeholders. And if we can create something better, cheaper, slicker, better… that has to be a good thing!

BATimes_NOV9_2022

Best of BATimes: 4 Business Analyst Interview Questions And Answers To Kickstart Your Career

Written by Jimmy Rodela on . Posted in Articles.

Published on November 7, 2019

If you’re just starting your career as a Business Analyst (BA),

 

knowing the usual types of interview questions can help you prepare to impress your potential employers.

After all, knowing the possible interview questions will help you prepare the right answers that will make you stand out from other candidates who are vying for the same position.

Although the requirements for Business Analyst positions vary depending on the company, there are a set of common questions that you’re most likely to hear in every interview.

These questions could range from a simple “Why a career in Business Analysis?” to more in-depth queries, like the kind of tools you use, so the more familiar you are with these questions, the better equipped you’ll be to ace your interviews.

To aid you on how to do just that, here are four Business Analyst interview questions and possible answers to help you prepare to leave a positive impression on your prospective companies.

Question 1. What Is The Role Of A Business Analyst In A Company?

As a business analyst, you play a crucial role in guiding businesses to improve their products, services, software, and processes through data analysis.

Plus, you can bridge the gap between IT and your employers to help boost efficiency and translate data into useful and actionable insights.

As such, you’ll need to emphasize the specific roles of business analysts. If you have experience in the field, discuss some of your previous functions with your interviewers.

BATimes Nov07 01

Here are some of the things you can consider to help you discuss the roles of a BA.

  • Business analysts can take on specific roles within a company project such as System Analyst, Application Designer, Business Planner, Technical Architect, Data Analyst, etc.

If you’ve played these specific roles in the past, expound on what you did and the solutions you came up with.

  • The job of a BA will vary based on the requirements of your potential employer – some BA roles may be limited to IT projects, with a few extending to marketing, accounting, finance, and more.
  • Your primary role as a BA is to help determine the needs of your company, uncover the problems – including using predictive technology to predict future issues (to some extent) – and come up with business solutions.
  • Aside from technical skills, your role as a BA will require you to have a good grasp on engineering concepts, possess leadership qualities, and excellent communication skills.

Question 2. What Are The Crucial Tools For Business Analysis?

There is a wide array of tools and software that business analysts use to perform several functions required of the role.

With that said, interviewers will ask you what the crucial tools are for business analysis so they’ll know which ones you’re proficient in and what you can bring to their company.

If you are proficient with tools like MS Office, Structured Query Language (SQL), Blueprint, programming languages such as Python and R, Tableau, and more, bring them up during the interview.

Most interviewers will also ask you outrightly about the tools and the training you are certified in, but instead of going through the whole list, bring to focus a few of your most recent ones.

For instance, if you have undergone a CBAP certification training course, then discuss how it has enhanced your skills and how you can apply it to your prospective company.

BATimes Nov07 02

Doing so helps give your potential employers an idea about your skills and proficiency, and whether or not you already have what they need or if they need to train you for specific tools.

 

Advertisement

 

Question 3. How Do You Handle Difficult Stakeholders?

Remember that being a Business Analyst means coming up with solutions, but you’ll also need to prepare for the possibility when your proposed solutions are met with resistance.

Many factors can contribute to this, but among the rest, human factors like – difficult stakeholders – might be one of the most challenging to handle.

Your potential employers will want to know how you can manage this type of situation since it is bound to happen in every company.

You won’t need to provide an entire outline of your answers during your actual interview, but keep these few points in mind when formulating your possible responses.

  • Spot your “difficult” stakeholders from the group, listen to what they have to say, and exercise a significant amount of patience.

If you cut them off or be impolite towards them, it will only lead to misunderstandings, and that will not help you resolve any of your issues.

  • Some stakeholders are difficult because they are not comfortable with some of the things in your project. So take the time to dig deeper into their issues by listening to what they say and answering any questions they might have.
  • As much as possible, meet and discuss with your difficult stakeholders personally as a way of showing them that you are committed to working towards the same goal with them.
  • Continuously engaging your difficult stakeholders helps them understand that their contribution is valuable to your project. Their resistance could also stem from valid points of view, so it’s crucial that you don’t just dismiss their opinions.

Keep in mind that there are no perfect answers, but being prepared for possible questions like this will always help you have concrete responses.

Question 4.  Do You Have Any Questions For Me?

Asking tons of questions comes with the job of being a Business Analyst, and one of the best places to demonstrate your ability to ask relevant and insightful questions is during your interview.

This part of the interview that you can turn into a conversation by asking questions about the company, its processes, and more.

Aside from demonstrating your abilities, asking relevant questions also shows your potential employers your interest in their company, which can only help increase your chances of getting the job.

BATimes Nov07 03

Here are a few questions that you can ask your interviewers.

  • “How does your company handle systems analysis, and do you have a dedicated systems analyst?”

There are companies with job postings for BAs when what they really want is a Systems Analyst/BA, so it’s best to clarify this ahead if this is not the type of role you would like to fulfill.

  • “Which project phases are your BAs involved with?”

If your interviewer says that business analysts are only involved in requirements, then the company might be looking for a Requirement Analyst specialist.

This might not suit you if you want to perform a deeper and wider BA role, so you should get this out of the way during the interview.

  • “Does your company have a central BA team, or does each function have its own BA team?”

Asking this question will help you determine whether or not there is a central team that will allow the pooling of knowledge.

Bottomline

There might not be perfect answers to your business analyst interview questions, but being prepared by learning the possible responses will help equip you for the big day.

Remember that being a business analyst means solving problems, and your interview Q&A is the first obstacle you need to overcome in a long list of challenges coming your way in a BA career.

Also Read: Business Analyst Manager Interview Questions

Did you learn something from this post? Please share this with your network if you agree. Cheers!

BATimes_OCT20_2022

Introduction to the Jack Method: Trees and Stories

Written by Igor Chebanenko on . Posted in Articles.

This is the farmer sowing his corn,
That …
…
That …
That lay in the house that Jack built.
An English nursery rhyme

A jack is a connector that installs on the surface of a bulkhead or enclosure.

 

The Jack method comprises techniques and concepts for comprehensive root cause analysis, scope modelling and requirements management. It is underpinned by the following principles:

  • ‘Simplicity – the art of maximizing the amount of work not done – is essential’ (Agile)
  • ‘Assume variability; preserve options’ (SAFe)
  • ‘Divergent and convergent thinking’ (Design Thinking).

The core techniques –Jack Trees and Jack Stories – are presented in this article.

The analysis is based on the Case study ‘The Good Kitchen’ where Danish government was concerned that Denmark’s seniors in assisted living facilities or residential care units had poor nutrition (https://thisisdesignthinking.net/2016/05/the-good-kitchen/).

Jack Trees

Intro:

Jack Trees are the key element of the Jack method. It allows to perform analysis in ambiguous environments with limited access to subject matter experts. Promoting identification of unexpressed assertions, it creates a traceable structure of requirements ranging from solution-agnostic business needs through to detailed specifications. Jack Trees are a perfect tool to make conversations with stakeholders productive, and to enable confirmation what’s in scope and what’s out.

Theory:

A Jack Tree is a hierarchical list of statements that follow a specific format:

  • Each statement delivers an unambiguous (and therefore short) message
  • A statement contains an action and an object
  • Statements in the hierarchy relate to each other as ‘one to many’
  • The statement of the higher level is called an ‘objective’, of the lower – an ‘option’
  • Statements are formulated in a way that options address the objective
  • The highest statement in the hierarchy usually corresponds to a Business Need, the lowest statements are usually acceptance criteria or specification items
  • Each statement can serve as an objective or an option depending on the depth of analysis.

To shorten the definition, a Jack Tree is a hierarchical list of action statements where each objective has at least two solutions.

To create statements, the Semantic Analysis and Minimum Meaningful Message techniques can be used (it will be described in a separate article).

Mathematically, a Jack Tree is a Directed rooted N-ary tree. Hence, specific properties such as terminology, relationship cardinality, isomorphism, calculus, etc. are inherited and can be applied to the Jack Tree.

Example of a Jack Tree branch may look like:

  • Improve quality of food
    • Increase meal nutrition
      • Add supplements
      • Increase meal size.

Algorithm:

The Jack Tree is all about alternatives. Each statement is to be challenged for an existence of a concurrent option. Alternatives are being identified and grouped under objectives, and objectives are reviewed to be matched, renamed or split, until the desired outcomes are achieved.

The ideal Jack Tree represents a logical flow of statements explaining how different levels of objectives can be addressed by a number of options. Every option is unique even if it looks the same – where there are identical or similar option statements, they still relate to different objectives providing a different context. It is also important to mention that it is never the only variant possible for the Jack Tree, as the analysis view can be changed based on new findings or analysis focus.

The short algorithm of a Jack Tree creation is as follows:

  • Create a semantically refined statement (action + object)
  • (↓ ‘look down’) Treating it as an objective, devise at least two solution options to address it
    • Where nothing comes to mind, try using the ‘Do nothing’ option
  • (↑ ‘look up’) Treating it as an option, devise an objective the option can be addressed by it
  • Refine wording where needed – it promotes solution-agnostic formulation
  • Continue moving up or down the Jack Tree, adding branches, objectives and options till the desired analysis granularity is reached
  • Consider the Jack Tree completed when requirements are detailed enough.

Once the Jack Tree is created, all options need to be reconfirmed with appropriate stakeholders. Talking through the options will evoke highly valuable insights on what the current and future states are, along with confirming the scope.

It is imperative to note that knowing what’s in scope is as important as knowing what’s out of scope. The Jack Tree technique gives a perfect indication of that.

Additionally, it is practical to use a ‘Do nothing’ option as an alternative where applicable. However, ‘Do nothing’ is an option that also requires an action, and should be equipped with associated acceptance criteria or specification, e.g. ‘Continue spending $1,234 monthly on support’. This allows for more careful scope considerations.

Application:

Building a Jack Tree can be started from a requirement of any level, looking up (confirming or generating possible objectives) and down (decomposing solution options to the desired level of granularity). It doesn’t matter how the requirement is obtained – through elicitation or formulation. In our case the possible initial requirement can be:

  • Increase meal nutrition.

It is quite easy to identify immediate solutions for the requirement – this is how our brain usually works. So let’s go with:

  • Increase meal nutrition
    • Add supplements
    • Increase meal size
    • Increase calories.

All second-level options satisfy the requirement by answering the question ‘What do I need to do in order to <objective>?’, e.g. ‘In order to ‘Increase meal nutrition’, I need to ‘Add supplements’.

Now let’s look up and check the correctness of the objective for every specified option: ‘If I <option>, would it <objective>?’, e.g. ‘If I ‘Increase meal size’, would it ‘Increase meal nutrition’? We can see that the objective and the options correlate perfectly.

Note that any of the options at this level can be broken down further (e.g. ‘Add supplements’ can at least be broken down into ‘Add vitamins’ and ‘Add minerals’).

Now, let’s test the ‘Increase meal nutrition’ statement as an option that has an objective. What purpose can this solution serve? What alternative would this solution have? Do all devised solutions correspond to the objective?

Please note that the most obvious answer ‘Improve health’ brings too broad spectre of solution alternatives:

  • Improve health
    • Increase meal nutrition
    • Visit a health resort
    • …
    • Do physical training.

It’s a signal that additional iterations are required to clarify and narrow down the Jack Tree branch.

After multiple iterations of the algorithm, a Jack Tree similar to the one below can be created:

  • Improve quality of life for seniors
    • Improve dining experience
      • Satisfy dining habits
        • Have dinner alone
        • Have dinner in a company
      • Improve quality of food
        • Increase meal nutrition
          • Add supplements
          • Increase meal size
          • Increase calories
        • Change food type
        • Change quality of ingredients
      • Make meal appealing
        • Improve meal taste
          • Change cooking method
            • Sear food
            • Steam food
          • Use spices
        • Improve meal appearance
          • Use separate boxes
          • Use pre-arranged meals
        • Improve range of dishes
          • Construct custom meals
          • Collect pre-orders
          • Introduce menu
          • Have multiple options cooked
        • Change food type
          • Change food consistency
          • Satisfy diet restrictions
            • Vegetarian
            • Gluten-free
            • Fasting
          • Improve food preparation process

Note that the analysis organically revealed true business needs confirmed by the actual Use Case, e.g. attention to cultural, reputational and behavioral aspects, and changing the cooking practices.

Unlike the costly and lengthy group effort during ‘The Good Kitchen’ initiative, the above analysis could be done by just one analyst within a day or two. This is where the real power of the Jack method resides.

Advertisement

Pros & cons:

A Jack Tree has commonalities with different techniques and concepts, but it has a number of advantages that are unique:

  • Identifies true business needs
  • Promotes solution-agnostic view
  • Establishes full traceability
  • Allows to operate with insufficient data
  • Provides a holistic Product view
  • Visualizes the scope not done
  • Clearly communicates the solution context
  • Promotes clarification of stated requirements
  • Allows for staged prioritization
  • Allows for effort estimation on different paths
  • Gives awareness of the entire backlog
  • Identifies gaps in analysis
  • Allows for algorithmic processing.

Once understood and adopted, the Jack Tree technique doesn’t provide any immediate downsides. Every challenge that occurs during the analysis, essentially improves the holistic understanding of the product, which is always beneficial.

Jack Stories

Intro:

A Jack Tree provides perfect input for traditional User Stories, and also promotes a specific story format – Jack Story, the technique that is part of the Jack method.

Theory:

The traditional format of the User Story is:

As a <Role>
I want to <Option>
So that I can <Objective>

As a Business Owner,
I want to Add supplements
So that I can Increase meal nutrition

When the role is insignificant or vague (which is often true for system-related requirements), an Enabler story format can be used:

IN order to <Objective>
WE need <Option>.

IN order to Increase meal nutrition
WE need to Add supplements.

A Jack Tree can immediately generate numerous conventional User Stories/Enablers, joining together Options and Objectives. Several stories may have the same ‘So that I can’ part, emphasizing different options for implementation that satisfy the same objective. This often happens ‘in the middle’ of the branches where options are being actively explored but haven’t got to the specification level yet.

However, the brevity of Jack Tree formulation may adversely affect the level of context provided. To alleviate this, a Jack Story can be used.

A Jack Story is a format of the requirement that traces an option to all its objectives up to a desired level. To build a Jack Story, a minimal Jack Tree branch needs to be created. Once the Jack Tree is available, the traditional formats of stories can be converted:

As a Business Owner,
I want to Add Supplements
So that I can Increase meal nutrition
So that I can Improve quality of food
So that I can Improve dining experience
So that I can Improve quality of life for seniors.

The same exercise can be done for the Enabler format.

A Jack Story gives a lot of additional context and indicates the way the logical considerations have been put into analysis.

Generally, the notion that a User Story is a Jack Story indicates that:

  • There exists a hierarchical list of options (Jack Tree)
  • Each statement in the story has been considered for an alternative
  • The story purpose is understood and is traceable back to the highest known element in the hierarchy (up to a Business Need).

It is not hard to notice that the Jack story format application for traditional stories is clunky and doesn’t sound natural, especially for longer constructions, or when the user focus is changed.

A new format of the story-like requirements format is therefore proposed. Analyzing the semantic structure of a solution option in the Jack Tree, we can see that it is represented by an Object and an Action. Breaking down the first option, and leaving objectives as is, the format of the Jack Story is:

This is the <Object> I want to <action on> (Option)
To <Objective 1>
To <Objective 2>
….
To <Business need>

This is the supplements I want to Add
To Increase meal nutrition
To Improve quality of food
To Improve dining experience
To Improve quality of life for seniors.

The Jack Story is the most natural and accurate representation of the Jack Tree requirements.

Empirically, when working on user stories organized in Epics, on average just 2-4 levels of requirements hierarchy are sufficient to provide enough context in the Jack Story. This makes Jack Stories more readable, concise and referable.

Pros & cons:

Jack Stories are a representation of the Jack Tree, and inherently obtain many advantages:

  • Fully compliant with INVEST criteria:
    • (I)ndependent – each option in the Jack Tree is an alternative that can be developed independently
    • (N)egotiatable – Jack Tree provides a variety of alternatives that can be selected on their own or broken down further until satisfiable
    • (V)aluable – each option in the Jack Tree has a reason to exist, therefore the value is well defined
    • (E)stimateable – looking up and down the Jack Tree gives a perfect idea of what an option comprises, thus making it easy to estimate
    • (S)mall – Jack Story formulation is dependent on the scale of view, and can be as small as needed for the development iteration
    • (T)estable – because Jack Stories are intrinsically short, Acceptance Criteria are an integral part of it.
  • Solution-agnostic at the high level, very descriptive at the detailed level
  • Short and concise, it fits easily on a story card and is easy to communicate
  • Naturally traceable
  • Unique and helps to keep the scope from creeping
  • Translates requirements easily from Waterfall to Agile
  • Promotes categorisation and critical thinking.

Along with the pros, there are some cons:

  • Requires creation of the Jack Tree
  • May need additional description and/or Acceptance Criteria
  • Not widely accepted hence requires explanation.

Jack Method

 

Jack Stories/Trees are powerful techniques for solution options analysis, especially when access to stakeholders is limited. To excel the method additional original concepts and techniques can be useful:

  • Semantic analysis
  • Minimum Meaningful Message
  • Traffic Lights (Semaphore).

The method makes scope better defined, requirements more structured, and prioritisation easier, contributing to the value of Business Analysis.

BATimes_OCT12_2022

How Does Agile Analysis Certification (IIBA(r)-AAC) Fit?

Written by Tom Tomasovic on . Posted in Articles.

Agile is here to stay!

 

Being a capable business analyst in an agile environment is no longer a specialization. Every competent BA must be comfortable working in an agile environment, and that should be reflected in the certifications offered by the IIBA.

 

Version 3 of the Guide to the Business Analysis Body of Knowledge (BABOK) was released in 2015. This version identified agile analysis as one of five sample perspectives that “provide focus to tasks and techniques specific to the context of the initiative”. Other perspectives included business intelligence, information technology, business architecture, and business process management. The expressed intent was that these perspectives represented common views of business analysis, and that they should be applied as appropriate in any project context to provide ways to approach business analysis work.

 

At the time, there were ongoing “debates” in the community regarding the need for or value derived from including business analysts on agile teams. Indeed, the identification of roles in the Scrum Guide: scrum master, product owner, developer, motivated many (misguided?) teams to specifically reject the notion of business analysts as necessary or desirable members of a Scrum team. This premise became common throughout the industry.

 

Advertisement

 

Parenthetically, I have always found it interesting that no one seemed to question the inclusion of testers as a specialized role on Scrum teams.

 

Why overlook business analysts? The question could generate an article unto itself.

 

As agile methods became more widely accepted, it was clear the business analysis domain needed to address this oversight. The IIBA partnered with the Agile Alliance to create and release version 2 of the Agile Extension to the BABOK Guide in 2017. The Extension was intended to demonstrate the need for business analysis in an agile context and to clarify the application of solid business analysis, independent of project context or development paradigm. The Guide “demonstrates how an Agile mindset can be applied to all domains and how any BABOK® Guide task can be performed in an agile context”[i].

 

In 2018, the IIBA introduced the Agile Analysis Certification (IIBA®-AAC). This was the first of their “specialty” certifications, expanding on the core certifications: Entry Certificate in Business AnalysisTM (ECBATM), Certification of Competency in Business AnalysisTM (CCBA®), Certified Business Analysis Professional (CBAP®). The certification was designed to be methodology-agnostic, focusing on the business analysis principles necessary to support iterative, adaptive development, independent of the domain. Some new techniques were introduced, but by and large, the focus was on how good business analysis practices described in the BABOK® should be applied in an agile context.

 

No one should argue that doing business analysis in an agile, change-driven context is the same as traditional, plan-driven analysis. The differences, however, focus largely on the timing and the level of detail in the application of standard BA practices. The same practices generally apply regardless of the team’s development approach.

 

Fast forward several years, and the agile paradigm is dominant in the software industry. Many organizations are extending, transitioning, or having transitioned to agile frameworks and methodologies. At the same time, those frameworks, methodologies, and teams have recognized that business analysis is not antithetical to agility. Indeed, business analysts or those project team members having strong business analysis capabilities are now seen as vital to successful initiatives.

 

Where does that leave the AAC? As of August 2022, the IIBA Certification Registry lists 1,474 registered holders of the IIBA®-AAC. This may not represent the entire total, as holders can choose to exclude their names from the directory. Compared with the other core and specialty certifications the numbers tell an interesting story:

  • ECBATM – 7,359
  • CCBA® – 2,743
  • CBAP® – 16,331
  • IIBA®-CBDA (Business Data Analytics Certification) – 338
  • IIBA®-CCA (Cybersecurity Analysis Certification) – 253
  • IIBA®-CPOA (Product Ownership Analysis Certification) – 634

 

Clearly, the core certifications are more popular than the specialty certifications. This is particularly true of CBAP®, which has been around for a longer time, requires verifiable work experience, and has more recognition in the marketplace. There is more interest in AAC than any of the other specializations, but that may be a result of the length of time AAC has been available in comparison to the other specialty certs.

 

What I find most interesting, however, is the integration of agile principles with the other specialty certifications. The IIBA emphasizes that the specialty certifications, particularly CBDA and CPOA, which is really an Agile certification, include the application of agile techniques along with an expectation of the application of techniques and practices from the BABOK®.

 

People preparing for certifications have a duty to understand more than just “what’s in the book”. To be an effective BA, the practitioner needs to be able to apply techniques and practices from any perspective that will support the initiative. In providing training for aspiring BAs and certification candidates, I often refer to information not only from the BABOK®, but also from the Agile Extension and a variety of other agile frameworks and methodologies.

 

Going forward, I can easily see the AAC being rolled into the core certifications, particularly at the ECBATM level. While that would eliminate one outlet for my services (AAC certification courses), I think it would ultimately serve the domain and result in better BAs.

[i] IIBA and Agile Alliance Release Version 2 of The Agile Extension to the BABOK Guide (https://www.agilealliance.org/the-alliance/news-press/iiba-and-agile-alliance-release-version-2-of-the-agile-extension-to-the-babok-guide/#:~:text=The%20Agile%20Extension%20to%20the%20BABOK%C2%AE%20Guide%20will,be%20available%20for%20enterprise%20licensing%20in%20September%202017)