Building Better Acceptance Criteria

As you can see from the widget on the right, I am speaking at the Building Business Capabilities conference this year. I’m super excited to be included as part of baf: Business Analysis Forum, billed as The Official Conference of IIBA. As far as I am concerned, there are three great confereces for BAs in North America, and this is one of them!

They have released the Conference Preview Guide for this huge conference, but I have included my information below so you don’t have to look too hard!


Building Better Acceptance Criteria Using Behavior Driven Development and Feature Injection

Thursday, November 3, 2011 11:30 AM
Building Business Capability: Business Analysis Forum, Fort Lauderdale, FL


It does not matter if you have a great idea for a software product; you have to communicate this to the developers building your system. Beyond user stories, developers need to understand the value and function they are building. They need good, or better yet great, acceptance criteria.

The secret to writing great acceptance criteria lies in Behavior Driven Development (BDD) and Feature Injection. The fabulous thing, besides the cool names, is they are easy to learn, easy to use, and produce better stories, requirements, tests, & code!

The heart of BDD and Feature Injection lies in using natural language to describe the value and features a system contains. Following a simple grammatical structure leads both writers and readers to understanding the goals and how they will be delivered. This process uses real examples, in business terms, to describe the behavior of the application.

While there are significant benefits for business partners, developers, and testers; one of the key benefits is how this turns Business Analysts and Product Owners from gathers of information to distributors. Rather than constantly pulling information from others, this provides BA’s the tools for pushing information out.

Attendees will leave understanding:

  1. Fundamentals and benefits of Behavior Driven Development and Feature Injection
  2. How to write better requirements / acceptance criteria using natural language and business terms
  3. How to easily develop real-world test cases to prove the feature is working as desired


About the speaker:

Jeffrey DavidsonJeffrey Davidson is a Lead Consultant with the global IT consultancy, ThoughtWorks, with deep experience as a mentor, coach, and trainer. An engaging and entertaining speaker, Jeffrey speaks with passion to audiences across the United States on business analysis and agile development.

Jeffrey has had many titles, including Director of Business Analysis & Quality Assurance for UTI, Business Analyst for Dell, Systems Engineer for Raytheon, and Product Manager for Ebay. He is a Certified Product Manager (PMC) and a Certified Scrum Product Owner (CSPO).

Jeffrey’s focus is helping organizations and Business Analysts transition to Agile, delivering great requirements, and building world-class teams.

Risk assessment

If the initial assessment of risk is not based on meaningful measures, the risk mitigation methods—even if they could have worked—are bound to address the wrong problems. If risk assessment is a failure, then the best case is that the risk management effort is simply a waste of time and money because decisions are ultimately unimproved. In the worst case, the erroneous conclusions lead the organization down a more dangerous path that it would probably not have otherwise taken.

Douglas Hubbard in The Failure of Risk Management: Why It’s Broken and How to Fix It

Training in the ring

Impossible is not a fact

Training in the ring“Impossible is just a big word thrown around my small men who find it easier to live in the world they’ve been given than to explore the power they have to change it. Impossible is not a fact. It’s an opinion. Impossible is not a declaration. It’s a dare. Impossible is potential. Impossible is temporary. Impossible is nothing.”

From the unstoppable, Muhamad Ali


Forrester: Where are you finding strong business analyst talent?

ApplicationI was recommended to check out the new Forrester Community (registration required) and on the front page there is an active question about BAs! Analyst Mary Gerush asked:

What are your best practices for either developing business analyst talent internally or finding external help?


I answered the question in the forum (as did @dwwright99), but I wanted to post my response here because this is something I am passionate about.


I have found strong talent can come from anywhere, but winnowing the field down to the person you should hire is a time-consuming process. Don’t get me wrong, I think you should take the time, but you need to know it is an investment of effort to find great candidates. I have spent 5 – 20 hours per week for 2 – 3 months to find a single hire in one market. It was a serious investment, but it paid off with a world-class team I could drop into any situation.

My preferred BA hiring process includes the following steps*. I like this order, but the middle steps can be moved around without significant consequence:

  1. Resume review, with a focus on a variety of experiences and a pattern of growth. I avoid candidates who have only recently been award the Business Analyst title after helping with a system upgrade. I expect to see 60-200 resumes per hire.
  2. Critical Thinking Skills assessment. This can be via paper, online, or a challenging problem face-to-face. I expect to lose at least 70% of candidates due to high expectations.
  3. In-depth interview. I prefer the Topgrading model by Bradford Smart, but Lominger can work. This should show the candidate has a history of continuous learning, relevant growth, and can achieve excellence in your environment. You should end-up with insights into their favorite work environments, what they think of past supervisors, and how they are best managed. If you take less than 90 – 120 minutes, you have not plumbed deep enough.
  4. Team interview. This includes 2-3 current employees. At least two BAs, the third may be from the business or IT, but must be familiar with working with a good BA.
  5. Skip-level interview. Meeting with the hiring manager’s supervisor. Optional.
  6. Discussion & Decision. This includes a rating of the BA in the areas below.

Here are the questions everyone should answer in the Discussion & Decision step:

  1. Does the candidate demonstrate the known competencies we desire?
  2. Is the candidate strong technically? [elicitation, documentation, understand our technology, etc.]
  3. Does the candidate have strong verbal communication skills? Are they strong enough at written communication?
  4. Are they a good fit? [in order: BA team, project team, Customer & IT]
  5. Should we hire them?

I believe the manager should have the final decision with the following exception: When the team unanimously agrees the person is not a good fit with the team, the candidate may not be hired. I generally treat the team as decision makers, at teams even arguing why a given candidate is good enough.

I do think it is important to always be adding new skills and capabilities to a Business Analysis team. Whether this is business rules, product management, understanding of data, facilitation techniques, ownership spirit, etc. every hire should add something new to the team. When this is followed correctly, it leads to continuous growth and expansion of capabilities. It also causes those early superstars to be eclipsed if they don’t keep up, but that is a different issue.


* I’ve left out any cultural fit or technical skills screening interviews, typically performed by a recruiting department. For the most part, I have found few screeners get to the level of insight I desire or add to the information I uncover during the in-depth interview. If I cannot use them to screen out a bad candidate, I don’t want to waste their time for these steps.


What’s your best practice? Please add your insight below.

If you liked this post about hiring great BAs, please share it using the links below.

5-years into a 20-year Process

I was commiserating with a former Requirements Engineer about having to write a Business Analysis Manifesto, discussing why the profession and skill set is not yet recognized for the value it can add. Then he asked a great question, “How do you think we’re doing?”

Pausing just a moment, I replied “I think Business Analysis is 5-years into a 20-year process.” We have made great strides in defining the role, competencies, technical skills, and expectations for a Business Analysis, but really, we are still at the beginning of the journey.

In my mind, we are in a struggle to remake the world. I am sure I watched too much TV as a kid, but I want BAs to emulate Oscar Goldman talking about Steve Austin, “We have the technology. We have the capability to build it better than it was before. Better…stronger…faster.” And have not reached our potential yet. [Some license taken in this quote]

Anyway, looking back over the last decade, I see a radical improvement in the average BA. We still have a long way to go, but we are so much better than we were before. When I started interviewing BAs I ran into many who were not ready for my teams. It was common to find a BA who…

  • … had never had a supervisor who understood their role, or gave them the right assistance and encouragement.
  • … had never been to related training or conference.
  • … had never read a book or blog post written for BAs.
  • … had invented most or all of their own tools and templates.
  • … were given the title because they were former super-users, helping with the last version upgrade, but didn’t understand the greater role or responsibilities.
  • … was a former developer, but never received the support and time to understand business needs and processes.
  • … and so on.

The expectations were so wrong, of course our profession was struggling! I used to draw the following diagram:

Expected versus Actual BA Skill Levels

You can see I thought we were terrible. And by “we,” I include myself in that chart. But the world of business analysis has drastically changed over the last few years.


Some factors in the change come from the much greater abundance of materials about our profession. You may not remember this, but BA blogs were big in the pre-fb, pre-twitter days and BAs globally started writing about their experiences. It was a heady time just to read the barrage of information being put out into the world.

And a bunch of BAs in Canada were so cold one winter day they said, “Hey, why don’t we form an organization dedicated to helping our profession.” In just 8 years, the International Institute of Business Analysis (IIBA) is now 20,000+ members strong, chapters in 61 countries, and working on volume 3.0 of the Business Analysis Book of Knowledge (BABOK). The amount of relevant knowledge codified by these volunteers is breathtaking.

Following these leading factors, conferences, books, and networking opportunities for the profession are much more prolific than they used to be.

Simultaneously, if not proceeding the above, companies of every size were living what we read in the Standish Group CHAOS reports. Projects were failing everywhere and it wasn’t too hard to figure out the need for requirements would be a significant help.

Now we know the problem with project failure is ongoing and much of corporate IT attention has turned to Scrum and Agile, but first they started hiring and building their Business Analysis capabilities.


Now, if you’ve read this far you understand my take on our recent history. But how does this translate into 5-years into a 20-year process? Of course, it’s just a guess–you never know where you are on the path to a singularity until it happens–but my guess is based on the following factors:

  1. I am once again explaining to corporations the role and value of BAs.
  2. I am surprised by the differences of opinions even among BAs, some of whom believe anyone can do this job and think we do *not* have responsibility for understanding the larger goals of the business.
  3. The basic understanding of competencies (ala Lominger) for BAs is rudimentary.
  4. The basic technical skills a BA should have are growing, but still spotty.
  5. I have found dramatic differences in expectations for our contribution based on corporation size, industry, SDLC, and even geography.
  6. Conversations with BA managers / directors and Center of Excellence leaders show me some of the ongoing conversations about our role and value are ongoing, been lost, and sometimes not yet started.
  7. Talking with authors and speakers shows me we are repeating the basic message many times over and seldom getting to meaty, difficult topics because the audience (which includes both BAs and almost always their working environment) is not ready for it.

I’m encouraged. We’ve made great progress; more progress than I dreamed possible six years ago, but despite some wins the journey has a long way to go.

Please subscribe or come back often to read as we make this journey. Together we will Be Amazing!

(My) BA Manifesto

I’ve been working, again, on defining and defending what a Business Analyst is and does. I mistakenly thought this was becoming self-evident and the battle was over, but it is obvious the war is ongoing. So, to guide my thinking as I re-engage in the battle, I wrote the following manifesto. Please review and comment, because