Author: Steve Jones

Ego Check: The Secret Sauce of Successful Business Analysis

Written by Steve Jones on March 14, 2024. Posted in Articles.

You’ve spent days or even weeks working through your discovery and analysis details to craft wire frames for a new application or capability. You know what your stakeholders might ask for in terms of alternatives, so you create those versions as well. The day arrives when you’re finally ready to share with business and IT, the work you’ve labored over.

The big meeting happens and your stakeholder destroys everything you’d worked so diligently over, ripping your heart out.

Sound familiar? Some people take this as a crushing defeat and question their choice of profession.

Don’t let this be you!

You need to have a thick skin in this game. As a business analyst, your role resides at the crossroads of business operations and IT solutions. Navigating the complexities and personalities of both requires not only some technical knowledge and business acumen but also a crucial personality trait — the ability to leave your ego at the door. While this notion may seem daunting at first, it stands as one of the most invaluable skills a business analyst can possess.

Bringing your ego along in conversations tends to add chaos, disrupting free-flowing communication in an environment that might already have some chaos. Setting aside your ego entails acknowledging you don’t have all the answers; that meticulously crafted strategies may necessitate revisions; and that your perspective, no matter how comprehensive, may not encapsulate the entirety of a problem or its solution.

Within the dynamics of a business environment, ego can often act as a hindrance, impeding effective communication. A business analyst who can restrain their ego is more amenable to guidance for research and receptive to feedback, fostering continuous learning and growth.

While criticism is frequently viewed unfavorably, it carries substantial value within a business context, serving as an indispensable tool for development when harnessed constructively. As BAs, our mission revolves around streamlining processes, enhancing capability & value, and facilitating change — tasks that demand perpetual scrutiny and re-evaluation. Feedback, including criticism, serves as a critical lense through which we refine our insights and strategies.

You need to be strong enough to withstand the critique to investigate what the underlying cause or comments are about. When the feedback seems overly harsh and does not feel like it is constructive, exercise what you have available to you – use your tools to continue the conversation. Start by expressing appreciation for the input. Depending on the harshness of the initial comments, this can be disarming, so utilize the connection to ask questions for feedback that could be actionable areas for your improvement.

In addition to seeking constructive feedback, you can also practice the agile principle of Simplicity. If you don’t quite understand what “the art of maximizing the amount of work not done” really means for a BA… it’s this; don’t spend so much time trying to produce a pristine wireframe or perfectly crafted requirement. Do enough to identify value during conversations.

While on a project or during a product increment, the initial requirements documentation is really intended to be just enough to draw out the valuable conversation to confirm understanding while narrowing in on the solution and it’s constraints to facilitate realization of the business value.

Internalizing feedback can obstruct the broader perspective and overall objective of the task at hand. Conversely, leveraging feedback as a means of self-improvement can significantly elevate your standing within the team, while enhancing the quality of output and fostering stronger work relationships.

Keeping your ego in check does not mean a dismissal of your ideas, opinions, or self-assurance entirely. Rather, it involves striking a balance — knowing when to advocate persistently for your ideas and when to step back, listen, and glean insights from others. For seasoned analysts, this should be second nature but it’s worth a reminder from time to time.

In conclusion, the absence of ego can quell the chaos, amplify your capacity to discover and comprehend the real issues, and embrace diverse perspectives to construct robust and effective solutions. Thus, resisting the urge to take criticism personally and ensuring that our egos do not overshadow the primary goal of problem-solving constitutes an trait every successful business analyst must master.

Improve Prioritization Using a Combination of Techniques

Written by Steve Jones on September 28, 2022. Posted in Articles.

Software development projects have a long history of unsuccessful delivery for myriad reasons. A lack of success is often determined by what didn’t make it into the final product release; like a core functionality, while some enhancement items did make it in. This begs the question, “Why weren’t all of the core capabilities the focus until they were complete?”

Rarely does everything in the requirements get implemented, so knowing the core capabilities is necessary to keep from getting derailed by enhancement requests. When a project includes multiple stakeholders, it isn’t uncommon they end up fighting for the wrong thing as it relates to the project, “their stories.” What gets lost in all the fighting over each stakeholder’s “priorities” is the real goal – achieving the right outcomes for and by the project.

What’s the problem?

TLDR: There are challenges when using just one prioritization technique to provide guidance of what to work on next.

User stories and requirements can be prioritized using several different techniques (Ranked Order, MoSCoW, Scaled, $1/$100, High/Med/Low, Story Mapping, Weighted Shortest Job First [or WSJF], to name a few), with different benefits and drawbacks to each of them.

Ranked order, i.e., setting out to identify the explicit order to be worked, is a very time-consuming challenge. Changes, whether from business decisions or technical limitations, can happen at any time during the project and cause a reshuffle every time they occur.
Using fixed amount methods to prioritize, such as the $1 or $100 methods, are good at giving clear indications of importance by virtue of the highest number. Fixed values limit the number of stories that can be created without resorting to restructuring the whole valuation system. On reviews and revisits, any change forces a recalculation of many stories.
Categories produce multiple stories with the same value (many ‘High’ or ‘Must have’) that do not always provide enough information to know priority. When there are so many with the same value, it forces a break in the effort to know what should be worked on next, unless a tie-breaking method is already defined.
Story Mapping helps manage the big picture of the project since it displays all themes / activities of users. The themes and activities are ordered along a top row, then broken down into smaller stories and ranked in priority. Early in the project, the number of stories and ranking effort is focused, more easily identifying high value functions / stories.
Weighted Shortest-Job First, WSJF (pronounced wiz-jif), rates each story on business value, time criticality, and risk reduction / opportunity enablement (the business valuation, known as ‘Cost of Delay’), as well as factoring in the IT effort to deliver the story. With several criteria getting a valuation for each story, it becomes easier to see the highest business priorities to work on next. This can still mask the core needs that must be delivered.

Another challenge to prioritizing arises with many of these techniques when new stories are added. Sometimes a key requirement is missed during early analysis or through story decomposition and story splitting. Other times, demonstrations of work inspire new requests or research identifies a new need. How are the new stories valued, ranked, categorized? Do the newly added stories all get the same value as the original when split or does the ranking need to be done again? What becomes of highly valued stories which are just enhancements? Enhancements may have higher business value than some core technical stories. Some of these techniques handle additional stories more easily than others.

Maintaining prioritization is a challenge in itself

Capturing all this prioritization detail can be a frustrating challenge but maintaining it over time is just as frustrating. If you have a software tool that can automatically adjust rankings, some of these techniques may not be as much of a problem. But what if you are using physical cards or sticky notes to keep it all organized? It becomes a tedious task to manage the series, which will drive some to stop updating after a while, especially after repeated changes. Choose your method of prioritizing wisely, you will likely use it often.

How do we solve it?

Story Mapping is an effective approach to keeping an eye on the big picture goals without getting lost in the details. This is beneficial as it provides a more complete end-to-end view of the project, in addition to providing a view of the lower-level details in accompanying stories. Each of these stories can then be identified as a core ‘must have’ vs a ‘nice to have’ enhancement.

Combining multiple techniques simplifies project priority determination. For example, utilizing the business valuation portion from the WSJF does a good job identifying the value for any given story. The valuation can be used for easier ranking without the need to constantly revalue everything below (see Figure 1). In addition to identifying the value of each story, it is very helpful to identify what is needed for core delivery and what is enhancement. When splitting a story, make sure core functionality is clearly differentiated from what may be an enhancement.

Taken in combination, stories are identified as a core delivery need or enhancement AND with each story’s individual business value (the number inside the ovals in Figure 1). While there may be enhancement stories with high value (sometimes viewed as the next shiny new thing), they may not be core functionality. Keeping the high-level view of core delivery items distinct from enhancements enables the focus to stay on outcomes. This perspective can be crucial to maintaining reasonable prioritization efforts in limiting unnecessary re-work of rankings, and identifying enhancement stories to address after all the core functionality is complete.

In the end, using more than one technique to manage project and product priorities ensures that the team is focused on getting the right overall outcomes, instead of persistent debate over individual stories. Practice quality communication and utilize your tool kit to experiment in finding what works best with your stakeholders and team.