TL;DR: Many teams ask for larger stories because they do not see how to slice the work into smaller chunks. When you give into this anti-pattern you are making developers work harder, and possibly decreasing the value of what you deliver. Write smaller stories and your team will be both happier and more productive.
As far as I’m concerned there are three skills a BA must learn to be great.
- How to ask questions
- How to explain concepts graphically
- How to tell stories
Everything else, and there is a lot to the everything else, takes second place to these three things. The first item is vital because it’s how you learn. The second two are vital because it’s how you should share what you have learned.
We deal in complex ideas. They are not simple. I regularly quote from Rich Hickey’s presentation to StrangeLoop 2011, Simple Made Easy. Rich discusses how difficult it is for us to really grasp multiple, interrelated concepts at the same time. As Business Analysts, this is exactly our job; to communicate multiple, difficult, interrelated concepts (MDIC).
And communicating MDIC needs more than just another document. It’s not that we don’t write a lot of documents, we do. (Yes, story cards are a document.) More important than the document is the understanding. And understanding MDIC doesn’t come best or easiest via the written word. If you want to build understanding, then you need to communicate based on how your audience will best understand. Being human, the best ways to get through to your audience is by pictures and stories.
With pictures (graphics) I see and understand relationships, order, hierarchy, proportion, and all kinds of other things. If the picture is good, I can do this is less than 10% of the time it would take me to read words describing the same thing. If it’s really good, I can do this in less than 5% of the time.
Now, it sometimes takes me 10-20 times longer to develop the right picture, so there are tradeoffs depending on the role and size of your audience, but never underestimate the importance of a good image. If you work with MDIC, you probably need a picture, or twenty.
If you are ready to improve your skills in this area, I suggest looking at the following resources:
- Visual Models for Software Requirements. Much of what I know about requirements gathering I learned while working with authors, Joy Beatty and Anthony Chen.* Find excerpts here and here.
- The Back of the Napkin: Solving Problems and Selling Ideas with Pictures and Unfolding the Napkin: The Hands-On Method for Solving Complex Problems with Simple Pictures, by Dan Roam. His first book was an instant hit because it was provided thought-provoking concepts about why to use drawings and how determine what type you need. I have not read his follow-up book, but some reviewers like even more.
- Anything by Edward Tufte. Seriously, I love all his work. I hesitate going to his website because I can easily loose a day there.
- More infographics than explanatory, but I also like Show Me the Numbers: Designing Tables and Graphs to Enlighten by Stephen Few.
- Visual.ly. Hundreds of great infographic examples. A good resource when you need a leaping off point for your idea.
* Author’s Note: I heartily recommend their book even though I do not yet own a copy. One, I have that much faith in them. Two, I am waiting to get a signed copy of the book.
What books and resources would you add to my list? Please let me know below!
Are you a scrum master, coordinating with another team? You might be told, “Why isn’t that done? It should be ready by now.”
Are you a business analyst, talking about a change that doesn’t impact today’s stories? You might be told, “Don’t mention it during the stand-up meeting.”
Are you QA, trying to determine if this is a bug or not? You might be told, “Don’t you see the developers are busy? Why did you interrupt them while they were coding?”
And so on.
It’s an epidemic. Agile developers treat their non-dev teammates as part of their personal fiefdom, there to serve. Preferably quietly, so you don’t interrupt their thinking while they are developing. And woe unto those who are not present when called upon.
Developers are the gravitational center of the team. Everyone and everything revolves around them. For the last 5 years I’ve been saying, “Agile is methodology by developers, for developers.” I’ve been watching this behavior for years. It’s irritated me for years. But is it wrong? Should developers be the center of a team’s universe?
Where’s the value?
First, we need to agree on a basic metric. The only time software is valuable is after it has been delivered to the users. Software sitting in on personal workstation doesn’t add value to a business or consumer. Software waiting for the next release cycle isn’t providing anyone any value. It might be “done,” but it’s not giving anyone any benefits until it’s used.
I’m a business analyst. It’s incredibly important to understand the business goals when you’re building software. A good scope document doesn’t add value. Detailed specifications don’t add value. Designs and tests and servers do not add value, either. Only working software—working in the hands of users—has a chance to deliver value.
Theory of Constraints (link)
If working software is the primary measure of how we add value (See Agile Manifesto Principles), then we need to organize the software development process to get more software out the door. How do we do that?
Eliyahu Goldratt, a physicist who became a management guru, noticed manufacturing lines were organized to maximize the use of all the machines. This was making accountants happy, but it caused problems with extra work, waste, and a growing warehouse full of partially completed products. Goldratt determined manufacturers can make more money by organizing their production lines for consistent throughput around the bottlenecks (constraints).
The same problems, and solution, affect software development. Agile provides a set of tools for software projects, optimizing for the bottleneck, developers. Keeping developers focused leads to a more productive team. Optimizing for developer throughput (for example, having BAs and QAs nearby to answer their questions) means working software is delivered sooner. Optimizing for developers means you increase the chance real value will be delivered. Because the real value of software comes only after it’s delivered, it makes sense to be organized around developers.
What about other bottlenecks?
The truth is, processes have more than one bottleneck. After you optimize for the first bottleneck, you need to be ready to discover the next one. It takes diligent focus to watch the process and work on the next bottleneck. You cannot stop at the first one; bottlenecks are everywhere and you need to continue to watch and optimize.
Developers, because of their role, have a huge number of bottlenecks. They need the right level of requirements, properly configured workstations, the right tools, a good environment for checking in their code, time to understand the technology stack, available test systems and data bases, automated tests, and so on. If you are on a project long enough, you may find this list whittled down. I have never seen it eradicated, but I have seen it get pretty small.
Unfortunately, and I think this was part of my ongoing frustration, teams are not good at optimizing for other parts of the process. I’ve been parts of teams where the biggest bottleneck isn’t with supporting the developers, it’s with the testing or requirements supporting development. It’s not that teams cannot say, “I see you need help over there.” Rather, they seem to acknowledge the problem and then think it will go away.
Agile is right. Organizing your team for consistent throughput of working software provides the most value to customers. Supporting developers leads to better software, quicker. It’s the teams that are failing the process. When your team has a problem, discuss it. Work on it. Eliminate it.
Agile isn’t just for developers, but it will be if you don’t pay attention.
Do you agree, is this the right way to develop software?
Do you think it’s a problem? Why? Please leave your comment below.
Have you ever heard this phrase?
“What gets measured, gets done.”
It contains huge truths about human nature, or at least my nature. I pay more attention to something when someone else is paying attention to it. I didn’t have to study the Hawthorne Effect to know this. Looking at my own life, there are lots of examples where if the boss was looking, I did my stuff. Where they didn’t care to look, I soon learned it was safe to ignore this area. And I often did.
More relevant to being a Business Analyst, I was brought into one company to train their new BAs. We spent lots of time covering the basics and then we started working on projects. The documentation was very uneven between the BAs (including me), so I said “Everything has to be peer reviewed before it goes out of the team.” And within a couple months everyone was writing great requirements. Really great. A couple months later, after we had stopped our internal reviews, the clarity and readability of our documentation was in the toilet. We had fallen back to our old habits. Just knowing a peer was going to review our work led everyone to do better work. There is no doubt in my mind, measurement and feedback can and do improve performance.
Unfortunately, most requirement metrics don’t help a BA, a project, or a team. They hurt it.
Typical Requirement Metrics
Measuring requirements can be difficult. Here’s a list of easy-to-gather requirement metrics:
- Quantity (of use cases, requirements, user stories, process flow diagrams, etc.)
- Volatility due to scope changes
- Volatility due to technical & design changes
- Volatility due to missed requirements
- Volatility due to changes to existing requirements
- Volatility due to clarification required
- Defects due to requirements
- Schedule variance due to poor or missing requirements
- Tool compliance
- Process compliance
- Comparisons of the above versus:
- initial estimates or baseline
- project phase
- project size
These metrics have a couple elements in common. First, they are relatively easy to measure and calculate, presuming you have the right tools in place. I think many requirement management systems have been sold because for the first time companies will have metrics about requirements! Second, they all help ensure a team is builds correctly and in accordance to the original vision of the product.
I think it is important to ask, “How do these measurements benefit a team or project?” When I look at the above metrics, the focus seems to be on comparing requirements from one phase to the next, from how well did we understand the needs at the beginning of the project to how what was built at the end, to ensuring the process was followed. These all help teams “build right.” Which is important, but I think it is significantly more important to ask if the team is building the “right product.” Take a look at Gojko Adzic‘s chart from Specification by Example:
This chart describes my very real concern about requirement metrics. They help us build right. They help us ensure everything is checked-off the list, but none of the metrics push us to break the mold and build something great. They help us build something we planned months ago. I want to reinforce BA behaviors that push us to ask hard questions, pushing us up the value stream. I want us willing to take a new direction because we can see a project could be better. We should love killing projects because the value has already been reached, or never will be.
If you want to improve teamwork, you need to reinforce behaviors that support acting like a good team member. If you reward people based on individual behavior, you are undermining the goal of improving teamwork. Similarly, it’s not uncommon to find metrics being misused. Sometimes the problem is minor, metrics are unused and the only impact is the wasted effort to gather and analyze them. Other issues include inappropriately punishing a team because of metrics and unintentionally focusing more on metrics than on delivering business value. None of these are part of the initial goal when a company or team decides to track information, but they are pretty easy to find.
When you have to measure requirements, the first thing I want measured is their quality. First, define what a quality requirement ( or use case, or user story, or . . .) looks like. Then audit everyone against the standard. This ensures the quality of what BAs produce stays high. If your team is currently using a different style, template, or process for every project, this step will also push for more process compliance.
In a similar vein, I encourage teams to ensure everything goes through a peer review. I’m not sure metrics around this are especially valuable, but it might help with enforcement.
Lastly, think about the dimensions in Gojko’s chart above. Think about what’s really makes a difference. Fellow ThoughtWorker and Agile Manifesto signatory, Jim Highsmith has a great talk on this and often discusses with executives interested in enterprise agility. You should read his post and learn more about the most important metric of all, delivered value.
Have you heard of Bloom’s Taxonomy? More importantly, have you thought about how you can use the taxonomy to give yourself a performance evaluation?
Benjamin Bloom led a team of educators in the 1950s to identify a taxonomy, or classification, of learning objectives. The committee broke the objectives into three distinct areas, Cognitive (knowledge, comprehension, and critical thinking), Affective (emotional response and empathy), and Psychomotor (physically manipulate body and tools / instruments). For more information, I refer you to Wikipedia and Don Clark‘s articles for more information.
For my part, I want you to focus on the Cognitive function. You can find a number of cool graphics displaying the domain with an online search, but for my part I want to focus on the following chart, taken from “Critical Thinking in the Management Classroom” (by Athanassiou, et al., full reference below.)
When reading this, I translate it into BA practices:
- The basics of our job start with Knowledge, learning about and defining our business’ domain, able to answer a developer’s questions about a given process.
- We daily demonstrate Comprehension, translating business process needs into requirements, paraphrasing and summarizing the business needs into the language of our multiple audiences.
- Application is where we start to prove ourselves, applying business expertise to answer questions and predict behaviors & outcomes.
- It takes deeps business knowledge to do good Analysis, understanding not only business definitions, but seeing patterns, recognizing hidden meanings, understanding the context of information, systems, users, etc.
- Synthesis is all about combining old ideas to create new ones, generalizing for given facts, integrating and designing.
- Comparing and discriminating, assessing options, and verifying the value of different ideas is part of Evaluation.
Note: Bloom’s Taxonomy was revised in 2000, changing the names from nouns to verbs and changing the order of the last two items. The new list is: Remembering, Understanding, Applying, Analyzing, Evaluating, Creating. It is worth considering if BAs should in fact spend more effort on Evaluation / Evaluating and have less need for Synthesis / Creating.
I want to argue every BA needs to be great. Every BA needs to be able to perform at all of these levels. Every BA needs to be perfectly fluent in each of the Cognitive domain areas. But do they really need to? I am better at some than others. In fact, I am better at some higher levels than I am at some lower levels. Does this mean I’m a bad BA? I don’t think so.
Imagine you could have your pick of three BAs. All three are very good at Knowledge and Comprehension. The first BA is outstanding in Application, applying all the knowledge they have learned. The second BA loves Analysis, in particular digging into business operations and understanding how it relates to business rules. The third BA lives for Synthesis, integrating old ideas into something that seems new.
Now continue imaging and tell me which BA would you pick for a project that has to combine information from four different systems into a single report? Which BA should go to the project with the stable team, supporting the finance department with regular upgrades and system maintenance? Which BA should work on building out a new CRM system to track all of customer interactions?
As you can see, different projects have different needs, different cognitive levels. And as individuals, we are better at some tasks than others. So what does that mean?
It means we need to understand and play to our strengths. It also means we need to acknowledge our weaknesses and look for the best way to support our project and team when the project does not match our strengths. You can partner with others on your team if Synthesis isn’t your strong suit. You can push more decisions to the team if your Evaluation level is weak. You can still contribute to a successful project when it needs one of your weak areas, but only if you are paying attention and diligently shoring up this level.
Here’s a checklist to think about your contribution to your current project, modified from Athanassiou’s paper:
- ____ Did you summarize the concepts / goals / stories / requirements covered by your business partners? (Knowledge)
- ____ Did you demonstrate you understood what this project was about by comparing it or contrasting it with other projects, requirements, applications? (Comprehension)
- ____ Did you connect the ideas from this project to other projects, initiatives, business goals, competitor actions? (Application)
- ____ Did you examine the business goals and requirements so that you identified the theories, assumptions, fallacies, and ways of organizing their ideas? (Analysis)
- ____ Did you explore the goals and use this exploration to build a new understanding of the business or formulate new ideas or solutions? (Synthesis)
- ____ Do your actions demonstrate you critique ideas and solutions based on an understanding of overall business objectives rather than personal opinion? (Evaluation)
Athanassiou, Nicholas, Jeanne McNett, and Carol Harvey. (2003). Critical Thinking in the Management Classroom: Bloom’s Taxonomy as a Learning Tool. Journal of Management Education, 27(5), 533-555. Available here (@ $32! for 1 day of access)
Hat tip to Chris Boynick for referencing the above paper and giving me more context to start digging into Bloom’s Taxonomy.
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:
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:
- I am once again explaining to corporations the role and value of BAs.
- 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.
- The basic understanding of competencies (ala Lominger) for BAs is rudimentary.
- The basic technical skills a BA should have are growing, but still spotty.
- I have found dramatic differences in expectations for our contribution based on corporation size, industry, SDLC, and even geography.
- 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.
- 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!
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