Dear Diary:

“This new CBAP® Certification may be my ticket to a more rewarding career. If I can just pass the test, I’ll have those letters at the end of my name and it may give me the edge in the resume selection/search process. I think I can pass the test with enough preparation, but can I walk the walk while I talk the talk? I also need to know if this effort is worth it in the end and what my goal is, in order to determine if the payoff in the end is suitable.”

Once I started to study for the CBAP® test by reviewing the BABOK® 1.6, I was totally consumed by all the possibilities of knowledge attainment. Then I found out that there was a heavy-duty application process, and the feedback from my peers made it sound a daunting task. Several had stopped completing the application because it proved to be much more effort than they had to spend on the task. Several were psychologically paralyzed by the volume of information that they suddenly had to document. I also heard of the application being rejected because of incomplete information or no proper documentation of business analysis tasks. It made me wonder if all the effort was worth the trouble. Once I asked myself that question, the ability to think clearly and handle the obstacles was much easier.

Why would business analysts go through all this effort simply to get a few letters at the end of their names? After all, the exam in still in its infancy, and there is no proof that it is really leading to better money, better jobs or a better life. I realized that there are people like myself who don’t use letters, money, prestige, or bragging rights as their primary motivators. There are people that are simply interested in doing what they love to do the best way they can. They want to learn, experiment, think, prove, disprove, try, fail and succeed with fresh ideas and proven methods. They are passionate, and it’s that passion that drives them to want to obtain this new certification. It is a way to make them better. When I realized that these were my drivers as well, there was no longer a question about Return on Investment for expended effort.

The application process really isn’t as bad as I thought, though I am admittedly not done with it. However, documentation of my hours over the last ten years has proven to be much easier than expected, and it really made me realize that I had accomplished much in that time frame. Reflecting back on my life as an analyst over time has shown not only growth in knowledge, but a certain maturing of my thought process and self-discipline. Just in the years I’ve spent in my current job, I’ve made huge accomplishments.

Related posts:

1. Diary of a CBAP-seeker: taking stock of my business analyst experience Dear Diary: “I’ve been an analyst for a long time...
2. Exploring the CBAP (Certified Business Analyst Professional) designation This morning I had the great pleasure of speaking with...
3. Is CBAP experience more or less valuable, depending on the maturity of the software organization? Recently I engaged in a brief Twitter dialog with @edilorenzo...

So I’ve officially caught the author-bug. Since publishing How to Start a Business Analyst Career I’ve received a lot of feedback that a similar resource is needed for active business analysts looking to advance their career. After some initial planning and research, I’ve officially started work on a new book, tentatively titled How to Advance your Business Analyst Career.

How to Advance your Business Analyst Career will be a guide to help business analyst professionals assess and advance their careers. The book will help business analysts explore career options, define career goals, and create a professional development plan. BA professionals will also find tools to evaluate their job as part of their career and take steps to advance their career using opportunities available to them. We’ll deal with common career challenges, including starting a new position, setting goals with your manager, completing a self-assessment, and handling difficult situations many BAs face. For the job-seeking business analyst, this book will provide help in preparing to find a new BA position, including information on professional networking, resumes, work samples, references, job search, and interview preparation.

While interviews provided a cornerstone of the first book, I’m hoping that reader input and feedback can help make this second book even stronger. I’ve already started gathering input by publishing some sections as blog posts and I will continue to do so as this idea unfolds.

I’m also looking for business analysts at any stage of their career who are willing to share their experiences. I’m looking for feedback in terms of issues you’d expect this resource to address as well as stories about career challenges such as taking on new business analyst responsibilities, earning a promotion, or helping build a more mature business analyst practice. No matter what your situation, I am sure you have a story to tell and an experience to share. Your fellow business analysts will appreciate you taking the time to share what you’ve learned, as will I by providing you with a complimentary eCopy of the book.

If you are interested in interviewing, please contact me. I’ll send you a preliminary list of questions via email and then schedule a time for a 30-60 minute phone call.

Related posts:

1. How to Start a Business Analyst Career — eBook published I’m excited to announce that without further ado, I’ve published...

When I first started working on an agile team, one of the habits I needed to develop was grooming  the product backlog. In an agile environment my week-to-week and day-to-day focus quickly became more integrated with what the development team was working on each sprint.  If I went  into a sprint planning session without a properly-groomed backlog, the planning session was not as productive as it could have been. I learned quickly to stay at least one step (but only a step or two) ahead of the development team to maximize our productivity.

Realize that requirements drive planning in agile

In agile, requirements (or user stories) drive planning. Requirements are managed in a product backlog of user stories. The user stories are ranked by priority and the highest priority items are detailed out.

I’m sure there are differing opinions on what should be done prior to sprint planning vs. what should be done within sprint planning.   On the teams I’ve participated on, we focus sprint planning sessions on understanding a handful of user stories in detail and planning the tasks it will take to complete the stories.

This means that prior to planning I have prioritized the backlog, detailed out the user stories with conditions of acceptance, and collaborated with the development team on an estimate for each story. In many cases I found that estimates actually helped the business prioritize, so we estimated early and often.

There is definitely a different requirements cadence when grooming the backlog versus finalizing a set of use cases or functional specifications. So I’d like to share some of the practices I’ve developed that seemed to benefit me and my teams.

Meet regularly with software developers about new stories

I meet regularly with my software developers to talk about new stories and requirements that are being considered. In these discussions, we estimate the story if we have enough information. I also ask questions to understand the constraints. Oftentimes I’ll come away with information about how we can constrain a story to keep it small or what detailed requirements would require additional work. If there is not enough information to estimate the story, I come away with some open questions I can follow-up on so we can estimate it the next time.

Sometimes these discussions reveal that something I thought was fairly small is actually a larger story and needs to be broken up. All of this information helps me create a backlog that the developers can work with during planning.

Prioritize the product backlog

Most SCRUM and agile books will tell you to rank prioritize the entire product backlog. In my experience, this practice creates an extremely large amount of overhead. The value in rank prioritization is really with the product backlog items that might be addressed in the next few sprints. As such, I tend to break product backlog items up into releases or group them together in a general priority. Then, for the items that we have the capacity to address in the next few sprints I help the business rank prioritize.

Detail out the highest priority product backlog items

As we head into sprint planning, I ensure that the highest priority product backlog items have detailed requirements behind them. These detailed requirements are captured in user stories. Along with the requirements for the story, I draft conditions of acceptance or the tests that need to pass in order for the story to be considered “done”. During sprint planning, we review the requirements in detail and often adjust them for clarity or to answer questions that come up. During the sprint, if the developer discovers a new condition or rule, we’ll often continue to adjust the user story so that the entire team has a shared concept of “done”.

Of course, these aren’t the only tasks. Among other responsibilities, I’m also meeting with the business to flesh out ideas and opportunities for future releases. But to keep up with the sustained momentum of an agile development environment, grooming the product backlog for the immediate future often takes priority and is the most critical contribution I make to helping the development team be successful.

Related posts:

1. An Agile Experience: My first product backlog In a recent poll about the BA role in agile,...
2. Defining the scope of an epic before listing user stories in an agile product backlog Agile teams typically differentiate between “epics” and “user stories”. In...
3. Thinking outside the project: implied responsibilities of an agile product owner The agile/SCRUM product owner (PO) is one of the most...

In discussions about the role of the business analyst, it is common to see professionals insisting on the importance of “going beyond requirements” when describing the BA work. These analysts argue that BA activities such as enterprise analysis and process improvement indicate the need for a broader description. Being myself a consultant who often works in activities related to business process modeling and process improvement, I fail to see the benefit of moving away from the term “requirement” when describing the work of a business analyst, and here I explain why.

The IEEE Standard Glossary of Software Engineering Terminology defines requirement as:

1. A condition or capability needed by a user to solve a problem or achieve an objective.
2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents.
3. A documented representation of a condition or capability as in (1) or (2).

The BABOK provides a very similar set of definitions (differences underlined):

1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
2. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification or other formally imposed documents.
3. A documented representation of a condition or capability as in (1) or (2).

Simplifying a bit these statements, it is possible to define requirement as “a condition or capability needed to achieve an objective” (solving a problem can be considered an objective–something toward which effort is directed–, and therefore doesn’t need to be explicitly mentioned here). Based on this definition, it becomes easier to view “requirements” as the core aspect of the business analysis work–even for BAs who don’t belong to the IT space.

Take, for example, business process modeling activities. Process modeling is used to generate a visual representation of the flow and control logic associated with a sequence of related activities or actions. A process model, however, is not an end on itself: models may be created to better understand how certain business scenarios are handled, to help identify problems in the flow, to detect activities that don’t add value to the business, etc. Process models, in most cases, become a source of requirements, helping the organization (and, in particular, the business analyst) identify the conditions or capabilities needed to solve a problem (for example, a bottleneck, or errors caused by a faulty interface between business units), or to achieve another objective (e.g., increase productivity by reducing the time to perform a task or eliminating the wait time between tasks).

Business analysts exist to facilitate organizational change. They study business problems and opportunities and recommend solutions to help corporations achieve their goals. In doing so, BAs are constantly involved in discovering, identifying, analyzing, negotiating, and documenting requirements that address business problems and opportunities. In this context, is “going beyond requirements” really important to define the business analyst role? What do others think?

Related posts:

1. When to stop analyzing requirements and start shopping for software solutions All too often we start shopping for software solutions before...
2. The myth of the “requirements contract” A few weeks ago, I posted about how to validate...
3. Making it Work Between Business and IT: Overcoming Analyst Ownership to Kick-Start Collaboration [guest post] Whether an analyst resides on the business or IT side,...

The initial meetings with a stakeholder can be nerve-wracking. Oftentimes projects come to us for “analysis” with very little detail. It can feel like everyone else knows more and is better prepared. Yet we, the business analyst, own the next step. Especially as new business analysts or business analysts in new organizations who have not yet learned the business, a bit of fear and uncertainty can creep into these early days on a project.

As I’m reading about in The Introverted Leader, you can support your confidence in uncomfortable situations through preparation, presence, push, and practice.

Preparing to elicit requirements

To prepare for an elicitation session, conduct as much research as you can to inform yourself about the problem and the existing situation.

• Talk to the sympathetic people first. This might be the person that hired you or your designated go-to person in the department.
• Learn the business and explore the system. Obtain as much insight as you can into how the business operates and the system works using the available information and tools.
• Start a list of key terms. If a glossary exists, use it as a reference to find the definitions of terms. Often you will find additional or alternate terms that are not included in even the most up-to-date glossary. Keeping terms straight can help you carve a more efficient path to real understanding.
• Start a list of questions about the system, about the process, the people, and about the project at hand. Think why, what, how, when, who.  Keep this question list handy as you meet with people about the project and use it to guide your discussions.
• If system documentation is non-existent, create models as you learn about the business and the system.

Be present in your elicitation sessions

Presence relates to how you handle yourself with others. If you are prepared, you should be confident and 100% present in your initial discussions. To create presence in an elicitation session:

• Use your list of questions and agenda items as a guide, but go with the flow. Once your stakeholders start talking, let them speak through their thoughts. While later in the process you make need to practice guiding conversations and even interrupting, your initial meetings should follow the energy of the stakeholders.
• Focus on seeking to understand stakeholder perspectives. Avoid second-guessing the questions you have or what you do or do not know. Keep it top of mind that this is your opportunity to learn more about the project and the stakeholders’ opportunity to unfold their perspective.
• Be an active listener — summarize what you hear and ask intelligent follow-up questions. But don’t be so worried about your next question that you forget to listen!
• Be OK with momentary pauses. Collect your thoughts, review your questions, and continue the conversation.

Push yourself to become better at elicitation

Push refers to getting yourself outside of your comfort zone by taking on new tasks. Through push you advance your capabilities and your leadership. Some ways to push during elicitation include:

• Find gaps in your understanding and find ways to fill them. This might require involving an additional stakeholder or asking for a demo or observation.
• Seeking out the perspectives of higher level stakeholders. Drop by an executive’s office or take advantage of a chance meeting in the hallway and ask for what they value the most in the project.
• Use a new technique as part of elicitation. Learn a new way of modeling or a new tool and incorporate that into your elicitation activities.

Practice eliciting requirements

Practice is about repeating behaviors, even if they feel uncomfortable at first, until they become part of who you are. As an analyst you want to grow into a professional who loses that initial feeling of fear — the unknown becomes a sought after challenge.

Some ways to practice elicitation include:

• Practice asking your questions and listening to the answers with a friend or trusted colleague.
• Anticipate the types of feedback you might receive and practice responses.
• Keep the momentum going by scheduling elicitation sessions. After every meeting, define the next step and make it happen.
• Keep yourself informed about new skills. Read books about elicitation, especially Ellen Gottesdiener’s Requirements by Collaboration, and incorporate these practices into your elicitation activities.

With consistent practice, you will be able to spend less time preparing and more time being present in your elicitation activities. As your confidence grows, you will be able to handle more ambiguity in the initial phases and more dissonance among your stakeholders– i.e. more challenging projects.

Your reward: confidence!

By preparing, being present, pushing yourself, and practicing, that uncomfortable feeling will be replaced with excitement and confidence. As has been reinforced for me by Jennifer Kahnweiler’s The Introverted Leader: Building Your Quiet Strength, becoming a better leader is about continuing to invest in your own personal and professional development, increasing self-awareness, building on your strengths, and choosing new challenges.

Related posts:

1. Reverse engineering requirements: how to explore the system When you are conducting a current capabilities assessment, it’s critical...
2. Reverse engineering requirements: Create a Work Plan By now you are probably ready to start meeting with...
3. Leading through transparency: the value of a requirements management plan Being a leader within your organization requires a consistent commitment...