Tag: Career

The World’s Theory – The History of Business Analysis & Evolution of the Business Analyst

Written by Michele Hermes on May 4, 2014. Posted in Articles. 1 Comment on The World’s Theory – The History of Business Analysis & Evolution of the Business Analyst

As we all know, the role of the Business Analyst has evolved significantly over the last two decades. As more companies have realized their need for strong business requirements to support their IT efforts, Business Analysts have achieved a permanent role in most organizations. But how did we get here and what sparked the birth of Business Analysis as a craft? This can be explained by what I call “The World’s Theory”.

From times past, more specifically, since the birth of the first programmable computer in the 1940’s until the early 1980’s, computer systems were used primarily by the government, universities and the companies that made computers.

Basically, they were the only entities that could afford to use technology. Not just on the cost front, but also the cost of time and effort. There were many reasons why technology was so expensive in these ways at the time, namely,

Data storage was very expensive and took up an enormous amount of space,
Data was difficult to access since the data was stored in one-directional flat files,
It was difficult to write programs to access the data,
There was limited functionality built around mainframe systems, and
The only user interface was achieved through the “green screen”.

However, in the 1980’s – early 1990’s, things started to change. Data storage became less expensive, relational databases were introduced, new object-oriented programs such as Java were invented and the first graphical user interfaces came into being. All of these events led to a boom in information technology and business’ and programmers went wild chasing “the next big thing”. But something was missing. Although information technology had advanced to where mainstream businesses could utilize computer technology to improve their business processes and more quickly react to changing business environments, technology actually started to become more expensive. Why?

The value of technology was apparent, but critical dollars were being spent on software rewrites, updates to meet business needs not previously identified, increase in maintenance costs and resolving software defects. As business users continued to interface directly with software engineers their needs got lost in translation. They simply could not speak “technology-talk” and articulate their needs effectively while programmers could not always interpret what the business users were trying to convey. Boom! The world of the business collided with the world of technology and the craft of today’s Business Analysis was born.

Now, pseudo-Business Analysts had been around for a while, but they were not Business Analysts as we know them today, much like Project Managers of the era were not known as we know them today. Business Analysts were usually called Systems Analysts and the role was typically played by a software engineer in addition to his programming duties. This was not an ideal situation for the previously mentioned reasons but mainly the difficulty in truly understanding the business model of the organization and applying that understanding to the technology solutions.

So in order to support the business model, the role of the Business Analyst had to be developed and has done so over the last twenty years. In order for IT systems to deliver success for the business, three factors need to be present: 1) the business needs must drive the development of technology solutions, 2) the implementation of a technology solution must be accompanied by the necessary business changes, and 3) the requirements for IT systems must be defined with accuracy. The Systems Analyst of the past was preoccupied with #3 but the operation of a business in today’s global economy demands all three be met.

The modern Business Analyst is not only concerned with the requirements, but also the meaning of the requirements.

Business Drivers – why do we need to make change?
Business Vision – what does the business look like after we make the change?
Business Objectives – how do we measure our success?
Business Requirements – what elements need to be implemented in order to realize the business vision?
Business Rules – what conditions govern the behavior of the implemented solution?

Notice that all of the above deliverables are preceded by the word “Business”. Hence, the word “Business” precedes “Analyst”. The Business Analyst is not just technically savvy but also in tune with the operational business model for the company. This allows the Business Analyst to be a well-rounded individual with skills to speak to business problems and define technology solutions.

And the importance of the Business Analyst has really been recognized in the last decade as businesses more readily seek technology solutions to complicated business problems. But because of the added business focus a Business Analyst provides, businesses have been able to utilize the Business Analyst to solve problems that do not require technology changes such as business process improvement, organization changes and the streamlining of operations. More and more, Business Analysts are becoming involved at an earlier stage of project work where they can not only define the business requirements, but outline the current state and future state of the business as it relates to the business problem and solution. You can also see Business Analysts taking part in the development of business cases with cost/benefit analysis as well as the selection of technologies to support the solution.

In the past, many businesses said, “Can technology help us solve this problem?” But the question no longer comes exclusively from the business perspective but rather from the technology strategists when they say “What can technology do to enhance the product offerings and market opportunities that exist for the company?” Information technology enriches the business offerings by not only supporting core competencies, but giving businesses the ability to focus on those competencies without the distraction of ancillary business operations such as human resources and supply chain. And Business Analysts are at the forefront of this concept since they can speak not only to the technology solution, but how that technology solution should be implemented to meet the market desires. This is how businesses achieve competitive advantage. Not by wasting time and resources on rewrites, maintenance and defects, but putting action in motion to use technology to better reach customers. And the Business Analyst plays a key role in making that vision a reality.

Don’t forget to leave your comments below.

Don’t Try This at Home Part 2

Written by Steve Blais on April 21, 2014. Posted in Articles. 2 Comments on Don’t Try This at Home Part 2

Summoning up the other side of the debate, here are some thoughts about why business analysis might not be a profession in itself. I am also bringing in some comments and opinions by a group of people each of whom I consider to be examples of “professional” business analysts. Ironically, they all seem to have adopted the position that business analysis is not a profession, at least for now.

As much as Mr. Blais has some good points about the profession of business analysis in the last article (Don’t Try This at Home part 1), I am presenting the opposing point of view. Business analysis is not a profession for the following reasons.

A Business Analyst for Life

When you think of the “professionals” – the doctors, lawyers, engineers, etc. – you think of people who are in that profession for their entire career and then some. A retired doctor is still thought of as a doctor. In the field of business analysis, there is a constant clamoring for the answer to ‘what next?” In articles, and around the blogosphere and discussion worlds, the question is consistently asked: “is there life after a business analyst?” In a recent series of articles Cathy Brunsting posited that business analyst was not a life long profession and suggested that business analyst “manager” or “leader: are the next steps, but offered several alternatives as ‘next steps”: product owner (for organizations engaged in Agile software development), Product Manager (for retail, manufacturing or distribution organizations). enterprise architect, business architect, account manager, and senior management. The latter has been my somewhat tongue-in-cheek response to the question of upward mobility: the business analyst is the future CEO.

All this is well and good, but it seems to argue against business analysis being a profession. The constant concern with “what do I do after I serve my time as a business analyst?” suggests strongly that business analysis is but a stepping stone or training ground for other occupations or professions. As such, business analysis cannot be a profession in itself. Doctors, lawyers, and engineers do not enter their chosen profession as a means to some other job or some other profession (with the possible exception of lawyers who sometimes practice law as a stepping stone to politics. (Although we don’t usually refer to politics as a ‘profession’ except in a purely derogatory fashion).

Who Am I?

A common thread among business analysts is to ask “what am I doing?” Questions are posted on the boards such as “what is your business analyst elevator pitch?” “What do you tell Aunt Susan when she asks what you do for work?” “What do you say to people at the cocktail party after you say ‘I am a business analyst?’ We don’t hear members of the medical or legal professions having to explain to someone what their profession is all about. A simple “I am a doctor” usually suffices. This is the earmark of a profession. While Mr. Blais suggests that the umbrella concept of business analysis having many subsets within it is a proof of profession, I see it the opposite. Until business analysis has a clearly understood and well known meaning and a clearly defined discipline to support that meaning, such fragmentation is precisely the reason it is not a profession.

The Accidental Business analyst

In one of my early articles, and my first LinkedIn post I suggested that most people practicing business analysis were like me: they got into business analysis accidentally. It was not their dream or intended career. I asked “how did you get to be a business analyst?” Most came from technical occupations while some slid over from business jobs. Some gravitated to business analysis when the organization added the occupational specialty to its job descriptions, and some were told, “you are now a business analyst, go analyze!”

The point is that unlike doctors, lawyers and engineers, none of us grew up wanting to be business analysts. We did not join the Future Business Analysts of America clubs, (In the US secondary school system, there are a number of school-sponsored organizations such as Future Farmers of America, Future Doctors of America, Future Lawyers of America, as well as clubs for budding engineers, astronomers, and other professions, including the arts.) We did not plan our education around a business analysis curriculum and get our degrees in business analysis. Such degrees are still few and far in between at the baccalaureate level and nearly non-existent in advanced degree levels.

A Degree of Business Analysis

In a conversation about professionalism in business analysis about five years ago, Kevin Brennan (Chief Business Analyst and Executive Vice President of the IIBA) suggested this definition in a tweet: “it can be taught in advance of practice, out of context”. Professions therefore are teachable whereas a practice can only be learned through doing. What is it that a business analyst can learn in “advance of practice”?

How can business analysis claim to be a profession when there are no educational criteria other than joining study groups to cram for a business analyst certification? Universities seem to be inclined to awarding certificates in business analysis rather than degrees in the subject. It was a major leap forward when some universities awarded an MBA with a specialization in business analysis. In other words, there is no professional path through the educational system to become a business analyst as there is in a recognized profession, such as law, medicine or engineering. Thus, business analysis is not a profession.

Back in 2009 Laura Brandau (bridging-the-gap.com) made some suggestions about what might comprise a business analysis curriculum leading to a profession. Last year Keith Majoos asked the same question. The answers were interesting and involved courses that many colleges don’t offer. Can you have a profession without concomitant education?

Amateur Business Analysts

If business analysis is a profession, then it should be reserved for business analysts just as the medical profession is limited to those who are legitimate doctors, and the legal profession to those who are qualified lawyers. However, we have instances of people in many other job descriptions playing the role of business analyst or simply performing business analysis. Adriana Beal (Bealprojects.com) has this opinion about professional business analysts: “I’m not sure ‘business analyst’ should be treated a profession, [but] rather a role that many of us play in various moments of our careers:” She also mentions that her husband, who is an engineer turned computer science researcher, is called upon to perform business analysis on projects on which he is working. I wonder if that would be allowed if business analysis were truly a profession.

David Wright suggests that “To me, it is not what you do, it is what you deliver. I deliver requirements, so if asked I call myself a ‘Requirements Consultant’. Some may see it as a restrictive ‘title’, but there is enough demand for the deliverable that I expect to keep doing it for as long as I want.” In other words, business analysis is not a profession, but one of many labels for those who deliver requirements

While Mr. Blais might point to that factor as meeting a condition of a profession, consider an architect who talks to the client to determine the requirements for the new home he is designing for them. Or the engineer defining the requirements for the bridge he is building. Or consider a moving contractor analyzing the contents of all the rooms and closets of your house to define the requirements for boxes, truck space, and men to get your belongings transported to another dwelling.

Are any of these business analysts? Mr. Blais might point out that while they are defining the requirements or doing business analysis activities, they are actually playing the role of the business analyst. He might also stress that the fact that other job titles are aware that they are performing business analysis activities is enough to substantiate business analysis as a profession. Mr. Blais might jokingly refer to those who play the business analyst role while performing another job description as ‘amateurs’ to distinguish them from those who perform the same tasks on a full time basis and in that way prove that business analysis is a profession. I argue that a ‘profession’ requires specific and specialized knowledge and expertise such that only those who part of the profession can actually practice it. No “amateurs”. We certainly don’t think of people playing the role of lawyer or architect at various times during their lives as the need develops, except, of course, in the movies.

Not only That…

I can hear Mr. Blais protesting that if business analysis is not a profession, what is it? Is it part of another profession? Certainly there is no profession of “business” although there are those who seem to believe that an MBA is a profession, although I am not sure what a “professional MBA” is.

Currently business analysis seems to be a part of many other professions. As Adriana and others have pointed out, project managers, software engineers, quality assurance specialists, stock brokers, etc., use the techniques laid out in the BABOK and other business analysis guides. So, I would submit that business analysis is a practice or collection of practices rather than a profession. Or, as Mr. Blais has said, the business analyst is a role to be played by anyone, perhaps without knowing they are playing it. And maybe that is where it should stay.

Duane Banks takes it one step further: “I’m beginning to see business analysis as something you do, akin to critical thinking. So, business analysis is a skill or a competency.” Not a profession, not even a practice, but a competency!

There is one more aspect that Mr. Blais does not mention, business analysis does not yet has an enforceable set of professional ethics and guidelines that as there is in other professions. A lawyer can be disbarred, a doctor lose her license to practice, There are boards and adjudicators and sometimes even laws to help police the profession, weed out the miscreants, and maintain the overall reputation of the professionals. As of now there is nothing of that sort for business analysts or those practicing business analysis. All business analysis has at this time is certifications, and a certification linked to experience does not a professional make.

And Yet…

While I join with the others who posted comments to Mr. Blais’ article last month in suggesting that business analysis is not a profession I am not saying that business analysis should not or cannot be a profession.. I am saying that it is not now, or perhaps it is not yet.

So, what is necessary for business analysis to be considered a profession alongside doctors, lawyers and engineers?

The fledgling business analysis profession must coalesce on its definitions and identify its own scope. The IIBA has released its new core purpose and that purpose seems to suggest a movement toward consolidating and codifying the central purpose for business analysis to create a set of principles similar to the Hippocratic Oath or other professional creeds. This will provide a unifying connectedness among all those who choose business analysis as a profession. In addition, the Project Management institute is preparing a Practice Guide to Business Analysis which defines aspects of business analysis as it applies to making projects successful. These two efforts, among others, may help create a single consolidated understandable definition of business analysis so when I say at a cocktail party “I am a business analyst,” people will immediately understand what I do. That will go a long way to gaining a seat at the table of professionals.

The education systems need to create the necessary professional preparatory training. Perhaps there might be a tie between the MBA and the business analyst. In other words, there must be some curricula for undergrads and graduate students to take that leads to a degree in business analysis. The preponderance of the course work would be in business and not in technology, focusing on communication skills and analytical techniques rather than defining requirements.

As business analysts we would need to somehow establish a set of guidelines for behavior and ethics that is enforced. This might bring up the concept of licensing and that might bring up the specter of government involvement, but that seems to be a part of the definition of “profession”, at least at the doctor-lawyer-architect-engineer level.

But most of all those who are business analysts and who are practicing business analysis have to believe that they are in a profession, that business analysis is a destination and not a step along the way to some other position. We need to stop being apologetic for being business analysts. We need to understand the valuable and indispensable service we provide to the organization we work for. We need to establish high standards for performance and behavior among business analysts and adhere to those standards ourselves.

I do, however, agree with Mr. Blais about one thing: there is an opening and to a degree, a need, for a profession for the business domain to match that of the medical and legal and engineering domains. And it could be, and perhaps should be, business analysis. While we are not a profession yet, we can be if we want it to be.

As I said in an answer to the question: “Is the business analyst a stepping stone to other positions?” after a long series of positive responses that listed what those ‘other positions’ might be: “Gee. I like to think that all the career changes lead a person to the ultimate position, that of business analyst. There is nowhere to go from there but down.”

Don’t forget to leave your comments below.

Is Business Analysis Undervalued?

Written by Daryl Chan on April 21, 2014. Posted in Articles.

Today I was talking to a friend about some cool work we’ve been doing recently around a “basics of BA capability uplift”, and were talking about the value of Business Analysis and Business Analysts here in Australia compared to overseas.

I offered the viewpoint that I felt Business Analysis is poorly understood and undervalued in general in Melbourne (my experience being mostly with large corporates). He agreed and compared it to his experience in Canada, where he did not find it to be the case.

What influenced my viewpoint? Well, the general attitudes I’ve experienced in my career as a Business Analyst, but more recently, some truly inspiring lines (spoiler alert: not at all inspiring) I’ve heard in the workplace recently, such as:

“So, what exactly does a business analyst do?”
“Just put the requirements into the BRD template, that’ll do.”
“I’ve taken my notes down as a mind map, and everyone else’s notes are quite linear. Ha, typical BAs!”
“The ideation stuff happens WAY before a BA gets involved.”
“Oh you don’t know how to do a PivotTable? Just give it to a BA to do.” (I think this one was my favourite.)

All the above of inspire certain feelings in me, some gentle, some a little more aggressive, but in general, something along the lines of below.

Communicating the value of business analysis

So why don’t people “get” business analysis and the role of a business analyst?

Well, I actually don’t think it’s down to the people who made the above statements. I think that their perception of business analysis is very much down to the way we (or we don’t) communicate what it is that Business Analysts do.
I believe that we need to take responsibility for communicating the value of the BA profession, firstly as individuals, and also as a community. (Side note: Kupe Kupersmith has recently written a great article here on a similar topic)

There’s a fine line though. Bear with me, I won’t suffocate you… yet. (via Cripplegate)

For instance, take a look at the some of the descriptions which have used to describe business analysis in the past. They’re all nice attempts, and whilst I don’t feel like they’re intrinsically incorrect, I also feel like they don’t adequately describe the full scope of what we can and actually do as BAs. They focus on the detail over the concept of Business Analysis.

Here’s a description which really hits the nail on the head for me though, and it’s straight from the good old IIBA website (and hopefully will be present in BABOK v3):

“Business Analysis is the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders.”

What’s different you say? The real beauty of this description is that each of the highlighted words come together in a dynamic, conceptual model, without a single mention of tools, techniques, “business and IT”, spreadsheets or Powerpoint.

Business Analysis Core Concepts Model

It’s called the Business Analysis Core Concepts Model. There is a fantastic article by Julian Sammy which goes into this model in more depth here. Make yourself a cup of coffee/tea/other caffeine mask before you start, but it is an intelligent, thoughtful, worthy read – here’s a quick summary:

Change: a controlled transformation of an organization
Solution: a specific way of satisfying a need in a context
Context: the part of the environment that encompasses the change
Value: the importance of something to a stakeholder in a context
Stakeholder: a group or individual with a relationship to the change or the solution
Need: a problem, opportunity or constraint with potential value to a stakeholder

Principles of Business Analysis

So whilst these core concepts articulate the areas we cover as Business Analysts, what is it that we actually do with regards to these concepts?

Laura Brandenburg has created this neat BA manifesto:

“Out of chaos, we create order.

Out of disagreement, we create alignment.

Out of ambiguity, we create clarity.

But most of all, we create positive change for the organizations we serve.”

Not bad right? It definitely resonated with myself and my colleagues as a call to action which sets a strong vision for Business Analysis. From this vision, we drew out four core principles which we believe best represents BA from an overarching point of view:

Bring stakeholders together
See the bigger picture
Facilitate shared understanding
Focus on what is valuable

I am sure there are many more principles (such as the ones suggested in Steve Blais’s article) which can apply, but we’ve decided for a less is more approach. Much like the law, I can’t remember every single rule out of the thousands which exist – but I certainly try live and abide by the principles those thousands of rules aim to serve.

Likewise, with these BA principles – no matter what tools or techniques we use, wherever we are in the product lifecycle, no matter how agile or rigid the environment is – they provide foundational beliefs which we can use to help organisations do better, and we can always link back to these and each of the six core concepts in every aspect of our work as Business Analysts.

This is how I see Business Analysis in my head, and in fact how we structured our recent capability uplift. Very keen to see how it’s depicted in BABOK v3.

How we might talk about Business Analysis in future

We feel that the combination of these two approaches set the scene for everything we do as Business Analysts. We believe it’s a succinct way of communicating the value of Business Analysis across the breadth of activities we can perform, but also hinting at the detail we can dive into when necessary.

Business Analysts can facilitate as much as we can set direction. We can help teams achieve business value as much as we can understand and communicate the ins and outs of a complex system. And we can sure as hell innovate whilst also being able to create super sexy spreadsheets which will knock people’s socks off- just as long as it’s valuable. Or brings stakeholders together by creating shared meaning. Or helps them see the bigger picture.

Do you even Excel, bro? (via Pixel77)

I’d love to hear your thoughts on the topic – do you have any thoughts on the questions below?

How would you describe the perception of Business Analysis in your community/country?
What do you think of the Core Concepts/Principles approach to describing Business Analysis?
What are you doing to communicate the value of our profession?

Until next time.
Daryl

Don’t forget to leave your comments below.

I Just Want to be “Accepted”

Written by Robert Galen on April 21, 2014. Posted in Articles.

Have you heard of the “3’C’s” of User Stories? It’s a heuristic to remind storywriters of the three key aspects of a User Story:

Card
Confirmation
Conversation

There’s quite a bit of debate as to what the most important ‘C’ is. Often in my classes I talk about “conversation” or collaboration being the most critical ‘C’. But to be honest, I have a hard time making a priority distinction between the three components of a user story.

In this article I want to explore an area that is often overlooked. It’s the confirmation-C. I sometimes refer to it as:

Acceptance Criteria;
Acceptance Tests;
Mini-UAT for each story;
Or Confirmation Tests.

Acceptance tests seem to be the most often used terminology. For example, leading to the notion of ATDD or Acceptance Test Driven Development, which can be a powerful side effect of how you approach writing your stories.

So let’s start with an introductory example.

Here’s what I would call an Epic with several related epics derived from it. We don’t have any acceptance tests yet, but we’re starting to develop a related set of epic-level stories.

As a writer, I want to allow for text font changes; 20-30 different font types, colors, so that I can highlight different levels of interaction with my readers
…Allow for various attributes: underline, bolding, sub/super script, italicize, etc…
Allow for a form of headings; 3 primary levels
Allow for indenting of text
Allow for lists (numbered and bulleted); single level first, then move to multi-level
Allow for alignment – right/left justified, centered, variable
Allow for do/un-do to include ongoing text activities
Establish a paragraph model (or a variety of models)
Show/hide ‘hidden’ formatting marks
Establish the notion of a “style set” that can be used to establish a collection of favorites

Let’s expand upon the second Epic:

As a Writer, I want to allow for various attributes: underline, bolding, sub/super script, italicize, etc. so that I can highlight different levels of interaction with my readers

We’ll start writing acceptance tests for this story. I have a preference for using “Verify that…” phrasing when writing my acceptance tests.

Verify that underline works
Verify that bold toggles for all font / color types
Verify that all combinations of all attributes can be combined
Verify that font size changes do not impact attributes
Verify that paragraph boundaries are not effected by attribute changes
Verify that attributes continue in pre-text, post-text ; for example, if we bold a numbered list text, the number should be bolded
You’ll notice in this case, that the acceptance criteria are all functionally focused. I don’t think that’s necessarily bad, but it would be nice to put in some significant error cases as well. For example, lets say that sub/superscript are not allowed in headers and footers for some reason. Then I’d expect the following acceptance criteria to be added to the list:
Verify that super & sub script are not allowed in Header or Footer areas and that an error messaged is displayed in-line and on the error console

I hope you see the clarity and value that solid acceptance tests can make to your story writing. I always refer to them as helping the 3 Amigos who are collaborating around story writing:

From a Development perspective: they should share design hints with the developer(s) exploring what’s important and the business logic behind each feature. They should share non-functional requirements as well, for example performance requirements.
From a Testing perspective: they should share some of the ‘How’ and ‘Why’ behind the customers usage and their intentions. The tester(s) should use this information to construct a series of tests that exercise the most important bits surrounding customer value.
From a Product Owner perspective: they are a rich communication landscape to augment the ‘C’ard of the user story. Typically the PO writes them in a grooming session with their team—so they are collaboratively explored and defined. They also serve as an acceptance checklist when the team delivers a ‘Done’ story for Product Owner sign-off.

This combination of roles (perspectives) surrounding the acceptance criteria helps to ensure the customer deliverable meets the need AND that you have a rich set of “tests” to confirm it.

Readiness Criteria

I often recommend establishing story readiness criteria that all of your stories must meet before they are “ready” to enter a sprint. From an acceptance test perspective, I’m looking for something like the following:

No fewer than 3-5 acceptance tests per story; no more than 10 per story
Of those, 1-2-3 that are focused on functional behavior
Of those, 1-2 that are focused on non-functional behavior
Look for positive and negative tests; for example error conditions
They should be as quantitative as possible
Each test should be independent
I can see as many as 10 acceptance tests for a story; but more starts looking like functional test cases
They should avoid being “process” oriented, for example, Product Owner sign-off as one of the acceptance tests

Now I’ve been exhaustive here in defining the readiness criteria for the article. In real life, only a few of these would be used or valid. I’ve found that establishing readiness criteria can be incredibly helpful in improving the quality of your sprint execution

(see the references for a link to an article explore them in more detail)

How do Acceptance Tests help?

First of all, I don’t think you can accurately estimate a story without identifying its acceptance criteria. For example, Epics in my experience often don’t have them and they’re estimated. But we’re not committing to those estimates and the story will be re-estimated as we break it down and refine the subsequent child stories. And of course, they will have acceptance tests.

So they help immensely in determining the true scope of a story and getting more valid or accurate estimates.

The also help in story decomposition. I often find that a fully defined Epic, with acceptance tests in place, will be easier to decompose. Often the acceptance tests will give hints or boundaries where you can break up the story.

If we go back to our example story, if the story was too big then we might start breaking it apart along the boundaries identified by the acceptance tests. For example—core attributes versus handling them in paragraphs and headers & footers.

Product Ownership

But ultimately they are “for” the PO. They are the mechanism to communicate priority-based business value. And they are the measure of a story being complete. I personally like the approach where a team brings stories to the Product

Owner whenever they’re complete, the PO checks out the story including running all of the acceptance tests, and then signs-off on the story being done. So from that point of view, the acceptance criteria are conditions of done-ness for each and every story.

Meta Acceptance

I have heard of a notion of Met-Acceptance Criteria that crosscut all stories that an organization will be writing. These are typically for domain requirements. For example,

I worked at EMC in the past and there was a lightly documented meta-requirement that no function (use case, story, feature) should corrupt data. Since EMC produced data storage devices, this made incredibly good sense.

So, did you need to mention this physically on each and every user story? We decided that the answer was no. That we would document it as a meta-acceptance criteria and teams would, when it applied, consider it as part of the stories acceptance testing.

I often find organizations describing these requirements for more non-functionally oriented acceptance criteria—particularly in the areas of security and performance.

Technical User Stories

Another area where a focus on acceptance tests will really help your story writing is with technically focused stories. These could be stories focused towards refactoring, infrastructure, tooling, bug fixes, testing infrastructure, virtually anything that is technically of value to the team but isn’t directly part of a customer facing feature.

With these stories, the criteria are focused towards expanding the design understanding of the story. Here’s an example technical story –

As a user requesting authentication,
I need to be able to login via the web app,
so that I can manage my account details via the web

Let’s spend a little time writing the acceptance tests, here are a few ideas:

Verify that all web-based requests get thru the service layers and receive a reply within 2 seconds
Verify that HTTP, Radius SecureID, and LDAP authentication protocols are supported
Verify that the authentication timeout performs at 25 seconds
Verify that 2-phase questions (3 in total) are presented every 3-5 login attempts
Verify that 2-phase questions are applied after a 3x password entry failure
Verify that password entry retry limit is set at 5x

I hope you can see how useful the acceptance tests are for this technical story and that the example gives you an idea of the distinction between the two types.

Wrapping Up

I was inspired to write the post/article by a colleague at Velocity Partners – Martin Acosta. He wrote me a note asking for references or help that would emphasize the role of acceptance tests. As I reflected on my writing, I realized that this was a ‘gap’ that I hadn’t previously addressed.

Martin, I hope you find some value in this post. And anyone “out there”, if you have examples of user stories and acceptance tests, please add them as comments. I’d love to see more real world examples.

And don’t forget, the primary purpose of the confirmation tests is to inspire, drive, initiate: CONVERSATIONS!

Stay agile my friends,
Bob.

Don’t forget to leave your comments below.

References

• Gojko Adzik’s book, Specification by Example, is a great place to go for a more deep and broad treatment
• The user story used in the first example was borrowed from this blog post
• Jeff Langr and Tim Ottinger talk about acceptance test characteristics that they’ve identified on their Pragmatic Programmer reference cards
• The technical user story in the second example was borrowed from this blog post
• Here’s a blog post on Readiness Criteria
• And finally, here’s a blog post on the 3 Amigos

Being a Personal Business Analysis Center of Excellence

Written by Aaron Whittenberger on April 14, 2014. Posted in Articles. 1 Comment on Being a Personal Business Analysis Center of Excellence

I am often asked how to best go about a particular business analysis scenario; how to do a particular technique. Usually the person is asking more than just best practices, but looking for a short-cut or one-size-fits-all process to go about doing business analysis. I hate to break it to you…there is no such thing.

What I often find in the question is that the person is getting hung up on the process or technique and has lost sight of the ultimate goal…which should always be to add business value. So in attempt to answer the question for all business analysis scenarios and professionals, I will give you my personal operating goals when conducting business.

Remember business analysis is not just the IT Business Analyst or Business Systems Analyst that works on IT projects to deliver software solutions to the business. Whether you are an IT Business Analyst, Enterprise Architect, Process Improvement Analyst, Data Analyst or one of the other business analysis roles, you have to interact with and build relationships with stakeholders and your ultimate goal should be to deliver business value to those stakeholders. So these operating goals relate to you.

There is no one-size-fits-all way of doing business analysis

There are many areas of business analysis that cover many strategic, tactical and operational roles within the organization. There are 34 techniques defined in the Guide to the Business Analysis Body of Knowledge® (BABOK®) version 2.0, and will be more defined in version 3.0 when it is released later this year. With that kind of breadth of coverage it would be impossible to have one simple way to do things. Even in a requirements elicitation activity, what worked last time, with that set of stakeholders, may not work this time with this set of stakeholders. Experience is the best teacher. Go into each activity prepared, ready to do your best and flexible enough to handle the different alternatives that can be thrown your way.

Be proactive not reactive

The best way to be proactive is to plan ahead. There is a whole chapter in the BABOK® concerning business analysis planning activities. It actually speaks about planning the business analysis activities for a software project, but as a practitioner you must plan for each activity you engage on during your work, whether software project or more strategic or operational activity. If you are working with a new line of business or business process that you are unfamiliar with, learn as much about it as possible before you engage in your business analysis activities. There are many techniques that the Business Analyst can use to learn about a business process on his/her own.

Guide, do not direct the conversation

Never go into an elicitation activity cold, be prepared to facilitate the discussion; but realize that the Business Analyst’s job is not to direct the conversation to a preconceived end, but guide the conversation to ensure that it is productive. You may walk into the activity with a preconceived idea of the way the conversation may go, but don’t mistakenly think that is the only way the conversation can go. When the conversation takes an unexpected turn away from your preconceived idea don’t attempt to stop it, allow it to develop and see where it may lead and what can be learned from it. Guiding the conversation means making sure side conversations are kept to a minimum and that everyone’s voice gets heard. You should never walk into a facilitation activity with the goal of forcing all stakeholders to agree on a particular point. It is alright to walk in with the goal of trying to get buy-in or consensus on a point, but if you do not get that consensus that is not necessarily failure.

No one is perfect

Your requirements, process model or design does not have to be perfectly written before you share it with the stakeholders with which you are working. Building these things in collaboration with the stakeholders usually produces better results. Remember that the business stakeholders and project team members that you are working with are not perfect either. They may not articulate everything just perfect or give you perfect feedback on your requirements or models. Seasoned professionals will work through these difficulties.

Work collaboratively with others

As I just mentioned working collaboratively with your stakeholders usually produce better results. The days of the Business Analyst conducting elicitation activities, running off to write the requirements by themselves and then presenting them back to the stakeholders is quickly coming to an end. When possible, write the requirements, or build the process model, during the elicitation activity. Spend the time with the stakeholder and work together to produce the requirements or design. The good by-product of this method is a much easier signoff of the requirements or design.

Learn from past challenges

You are not perfect. The people you work with are not perfect. Don’t think that everything you do will be perfect or end in success. It was Colin Powell that said “There are no secrets to success. It is a result of preparation, hard work and learning from failures.” Failure is not a failure if you learn from it. When something doesn’t go as expected, take a moment to reflect upon the activity and your role in it. What could you have done better.

Learn from others

No matter how long you have been doing Business Analysis, no matter how “Senior” or “Lead” you think you are, you can learn from others on the teams on which you work. Everybody in the organization may look to you as the subject matter expert (SME) in business analysis, but that doesn’t mean you can’t learn. If you are open to it, you may be able to learn from that Business Analyst that the company just hired last week. Look at the way other team members operate, what they do good and what they do bad. Incorporate the good into the way you operate. Also remember, you can learn from others doing activities outside of the business analysis space.

Always drive from the business need and the “why”

I have seen business analysts get so caught up on the particular activity or technique that they are doing that they forget why they are doing it. They may be trying to be so perfect that they lose sight of the goal. The Business Analyst’s ultimate goal should be to add business value, but they should know the goal of each activity that they undertake. Now that you keep the goal in mind, determine the “why”. When investigating a new area or business process, get to the “why”. Why do the people do it that way. What is the business value of doing it that way. I have heard it said to ask “why” five times (The 5 why’s). It may not need 5 times, but asking “why” multiple times is a good process to get to the underlying root cause.

Become the trusted advisor

The goal of your business analysis activities should be to add business value. The goal for you in the Business Analyst role within the organization should be to become the trusted advisor. You have to build relationships with all the stakeholders in the organization from your technical team members, project managers, business stakeholders, IT management and business management to build the trust so that these stakeholders will give more weight to your recommendations. When your business stakeholders see you accurately representing their points of view, when IT and business management see you working for the best interest of the organization and working to add business value, trust will grow and you will find your work easier to perform built on that trust.

Continuous Improvement

No matter how long you have been doing Business Analysis, no matter how “Senior” or “Lead” you think you are, learn from others and learn from past challenges and successes. Not only work to become the trusted advisor to everyone in the organization and to add business value; but work to hone your own craft. If you think that you’re so good that there is nothing more for you to learn, I would say to you “get over yourself”. The business analysis space is changing dramatically and will continue to over the coming years. There are new and better ways of doing things being discovered all the time. If you are not consistently working on improving the way you do business analysis then you are standing still and the world, and your organization, will grow beyond you. So continually look for ways to improve your own processes.

As you can see there is a lot to business analysis, inside and outside of software development projects. The Business Analyst cannot stand still in their way of doing things. The business analysis profession, the business environment and your organization are continually changing and growing. The only constant in the universe is change. The Business Analyst professional must change also. Grow in your understanding of business processes, your profession, your organization and the environment in which it operates. Stay up on the latest trends and look for ways to incorporate the way you do your business analysis activities.

Don’t forget to leave your comments below.