Tag: Career

The Road to Being a Business Champion is to Train Like an Olympian

Written by Richard Lannon on May 4, 2014. Posted in Articles.

Have you ever admired the strength, flexibility and endurance of an Olympic Athlete? It takes a lot of dedication to become a successful athlete. Olympians are at the apex of perfection. The fact that they get to go to the games is amazing, but to win makes them champions. There are secrets in training and preparations that Olympic Athletes have that increase their potential for success. As business leaders we can learn a lot from Olympic Athletes to help us become business champions.

Here are a few tips from the best of the best:

Have a Plan: It is amazing how many business leaders do not have a plan–they just wing it. The reality of being a top athlete is that you must have a plan. From diet, to workouts, to rest, there is a plan of focused intent. Know what it is you want to accomplish and why it is so important. Have a strategic road map for your business success.

Create a Routine: A routine is everything. It is part of your plan. Routines require an emphasis on high value activities. Focus on those things that will make a difference to you and your business. Schedule them in and make sure you do them.

Take Care of Yourself: Top performers usually have off-the-chart energy. How do they manage this? They take care of themselves through a healthy dose of proper eating and rest. Even the greatest boxer who ever lived, Mohammed Ali, ate well and rested. He took one day off a week to relax and ease his body and mind.

Proper warm-up and recovery: If you are going to work hard then you need to ensure you have proper warm up and recovery. This includes creating a natural rhythm to your business, as well as building in agility and flexibility. This is something that should be part of any good business practice. You and your people need to ensure they take the time needed to remain limber and prepared.

It’s all in the Head: Mental preparation is all about psychologically preparing for the big events. It is easy to get psyched out and think you or your people are not good enough. You need to tell yourself and your team they are the best at what they do. Create mindful rehearsals, read inspirational books, or count your blessings daily. Whatever it takes to build the mindset of a champion.

Consider a Trainer and Coach: Great athletes have coaches–we all know this. Business leaders who want to mix it up know they need help. From motivation to accountability, a coach can make a difference.
Be dynamic on your business: You can’t just focus on one thing in your business. You need to consider all the moving parts and train yourself in those parts. Olympic Athletes switch things up using fixed to variable equipment; they run, jump, throw, row, and do a lot more. The key, they mix things up.

Engage your People: Olympians have a team of engaged people who are rooting for them. It includes many key stakeholders including family and friends, sponsors and vendors, managers, coaches, trainers and peers. Engaging your team is important for your business as well. It is important you find a way to connect your people to what it is you want to accomplish. Engage the people that are in your corner.

Prepare for Heavy Lifting: All champions need to build their strength and endurance. Find ways to build your ability to deal with the events that are the heavy lifting of your business success. Build core competencies in yourself and those around you. Part of an Olympic Athlete’s heavy lifting ability is having a strong, engaged core. The same is true in business: businesses without a strong core tend to have more challenges. . Make sure you have engaged your core.

Train Early in the Day: Common wisdom says to train early in the day. Most Olympic Athletes do. Create an early ritual of getting focused, reviewing your strategic plan and the work plans that you have laid out. Focus on building up skills that will take you to where you need to go.

Build your Training Team: A dedicated team is everything for a Champion. You must have a team that will not only work with you, but also train with you. Olympic athletes are known to train together for years before they turn to competing against each other. Therefore, a training team can include your peers, your team and your competitors. Olympians train with their competition so they get better.

In business we ultimately want to be the best at what we do—we want to become champions. One of the best places to look for inspiration is at our Olympic Champions and the hard work and dedication they put into being the best at what they do. Like them, the first step to becoming the best is to think and act like a champion.

Don’t forget to leave your comments below.

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