Skip to main content

Tag: Skills

BATimes_Jun28_2023

Complexity Science Terminology Applied to Business Requirements

Borrowing from the terminology used in the complexity science field, in which systems are classified as Simple, Complicated or Complex, this article provides a short description of these characteristics, and suggests using the same terms, in a different interpretation, in the context of documenting Business Requirements.

In the book “Getting to Maybe: How the World Is Changed: Westley, Frances, Zimmerman, Brenda, Patton, Michael” the following meaning is given to the three types of systems:

<<Simple>> systems are based on a small set of rules or steps to function. They are robust, in the sense that the same input will generate the same output, with little variance. An example would be baking a cake by following a recipe.

<<Complicated>> system have a high number of rules and laws, even thousands, like the project to launch a spaceship to reach the Space Station. These systems can be managed by computers, are considered predictable, but they are not necessarily robust: an error in an input parameter can lead to a different outcome than desired (the spaceship ending up on another place instead of the Space Station).

<<Complex>> systems are those in which the component agents interact amongst themselves and adapt to the new conditions. For example, raising a teenager is complex because teenagers change their moods, they interact with their peers and the environment, and they adapt to the new context. Such systems are emergent, and other examples include languages, a pandemic spread, or the car traffic.

 

We can adapt this complexity systems terminology to the situation of a Business Analyst who is part of an on-going project to enhance an ERP application (Enterprise Resource Planning) in a specific organization.

In this framework the starting point are the business users who face the real world and have <<Complex>> problems. The role of the Business Analyst is to translate that complexity into a form that is <<Complicated>> but fully described. The final form of this translation is the Business Requirements Document, aligning the understanding of the requirements among the team members, with sections detailing <<Simple>> logical components.

 

From this perspective regarding the Business Analysts’ work, the categories are:

<<Complex>> problems known by the business users. These problems may touch several areas of the ERP, have unclear or vague rules, or the granularity of the logic and desired actions is not fully explained.

<<Complicated>> requirements with a high number of rules, parameters, procedures, algorithms. With the huge computing power available nowadays, ERP applications are able to handle such complicated systems, and they routinely process huge number of transactions run very fast on large databases.

 

Advertisement

 

Using the complexity lens to look at requirements provides benefits such as:

First, this perspective can reduce the frustration within the project team around requirements, by emphasizing the complex and changing nature of the business user’s problems.

Second, it increases the appreciation for the Business Analysts’ role in the team, since their talent and ability to translate <<Complex>> problems into <<Complicated>> requirements are key in this framework.

Lastly, untangling complex problems requires judgment, intuition, and context sensing – all characteristics that are unique to the human mind. In the current environment dominated by Artificial Intelligence applications, a Business Analyst with this view in mind would have less to worry about a being replaced by a robot and losing their job, if they see themselves from the position of contributing to the translation of complex problems into complicated requirements.

 

Equipped with the tools and techniques recommended by the BABOK, Business Analysts are in a unique position in the process of documenting the business requirements.

The following components of a Business Analyst’s toolkit are particularly useful in the requirements elicitation and documentation described in this framework:

  • Offering mock-ups and diagrams: Visual representations of the requirements can be highly effective in helping stakeholders understand the proposed solution.
  • Setting up test cases in the ERP application, to assess how well the information currently provided by the ERP system can support the proposed changes.
  • Performing a gap analysis between current and future state. This technique helps ensure that the requirements align with the overall business objectives and can serve as a basis for defining the scope and priorities of the project.
  • Organizing walkthrough sessions to gather feedback and ensure that the requirements are accurately captured. Business Analysts can generate and present iterations of the BRD with revision points, and address follow-up questions from stakeholders.
  • Asking open-ended questions to encourage stakeholders to share their insights, perspectives, and concerns, which can help uncover hidden requirements and potential issues that may not be captured through closed-ended questions.
  • Nudging the discussion towards “what” is the ultimate need, instead of the “how” to meet that need. This approach encourages stakeholders to articulate their true requirements and avoid premature solutioning. This approach allows for more creativity and flexibility in exploring different options and arriving at the most appropriate solution.
  • Being flexible in case the requirements change in time as the project progresses. and appreciate that the scenarios might be unchartered territory for the users themselves.
BATimes_Jun21_2023

User Stories: A Vital Step to Craft Successful Software

Simple and easy-to-understand user stories are the key to designing and developing successful software applications (products). Mastering the art of writing user stories is crucial for product owners and business analysts. Want to explore more about user stories? Here you go!

 

User Story 101

The foremost step in developing a project is to have a clear view of what needs to be created. Clarity is the most crucial element in software application design and development to end up with the most efficient solution.

User stories are the step-by-step documentation of a process, which describes the actions and results. It is an agile software development tool that mentions the features from the users’ perspective. The well-documented user stories are the foremost step in the agile development process to design and develop a software application that users love to use.

The primary purpose of writing a user story is to define project deliverables and how they will bring value to the user. No matter how complex a product or project can be, user stories are always written in simple terms. It needs to be as simple as possible so that a non-technical person can understand the document. There are some key considerations that make the creation of user stories even easier.

 

Key elements of a user story

  • Simple, straightforward content
  • Keeps users at the focal point
  • Collaborate with team members to gather details
  • Emphasis value deliverables

 

Apart from this, Business Analysts should also focus on making the entire teams’ and stakeholders’ participation by adding an INVEST element to the user story.

 

I – Independent (Self-contained without overlapping actions)

N – Negotiable (Keep the scope for negotiation to design a user-centric product)

V – Valuable (Must deliver values to the end users)

E – Estimable (Estimate, prioritize, and fit into sprints)

S – Small (In the form of small stories to complete in a couple of days)

T – Testable (Confirmation via pre-written acceptance criteria)

 

These elements are crucial in writing well-documented, to-the-point user stories to initiate the product development process. Once you understand the basics of user stories and how they should approach, it becomes easier to create those accurately.

 

Advertisement

 

Now that we have understood what user stories are and their key elements, let’s explore why Business Analysts need to master the skill to write definitive user stories. 

 

Why a BA needs to master the skill to write user stories

User stories are the foundational documentation that works as a blueprint while working on a project. The simple and easy-to-understand documents help the entire team to adhere to the project requirements and develop user-friendly features and functionality.

Moreover, it offers a contextual overview before the initiation of a project so that the team can understand what they need to work on. Also, they can think creatively and employ their best efforts to craft a user-centric product.

 

The most important benefits of user stories include.

 

  • Higher clarity on business values and project deliverables
  • Improved collaboration and visibility across the team
  • Prioritize features and functionality of the product
  • Efficient use of the end-users’ feedback
  • Minimize potential risks like communication gaps, technical flaws

 

As the user story conveys information about potential users and their actual needs, well-written user stories are essential to developing function-rich software applications. Business Analysts should understand the concept of user stories and focus on crafting user stories that drive value for the businesses via developing user-centric products.

 

When user stories are created

Generally, user stories are written at all software development stages BEFORE the development is initiated. Especially, while shaping product ideas, prioritizing features, and functionality, and during the development phase.

 

Who is involved in creating the stories

Business analyst, product owner or project manager, development, and design team, and sometimes stakeholders. Primarily, a business analyst or product owner writes the user stories; however, the entire team’s involvement is essential to create well-versed user stories that contribute to developing a user-centric, feature-rich software application.

 

How to create user stories

User stories are generalized documentation of why the product (software app) will be created and how it will take action. Here’s a simple way to create user stories that lead to a successful project development process. As mentioned earlier, keep users at the focal point along with what and why.

 

  • Who is the user story for?
  • What action is required?
  • Why is the action important?

 

The most commonly used format to create a user story:

As a <user>, I want to <complete this action> so that <I want this function>. Business analysts and the other team members can add other details to make the user stories to-the-point document.

 

Examples:

  • As a <user>, I want <to have to sign up feature> so that< I can log into the system>
  • As a <customer>, I want <to receive text notification when the item arrives> so that< I can pick up the item right away>.
  • As a <customer>, I want <to have online payment terminal> so that< I can pay online for purchases>
  • As a <manager>, I want <to generate multiple reports on dashboard> so that< I can monitor team’s progress>

 

In short, user stories need to be created before product development initiates. The understanding of users and what actions they need to take and why the action is necessary must be reflected in the user story. A well-documented user story will aid in creating a blueprint for project development that will lead to a successful software application. Usually, a product owner is assigned to form user stories; however, a business analyst must know how to create user stories that drive the design and successfully develop a product or software.

BATimes_Jun15_2023

Ten Tips for the Young BA

After ten plus years of working as a business analyst, I wanted to highlight a few things that have tremendously helped me become a better BA and advance my career.

As a young professional, I did not have many special talents, skills, or academic education, but I was not going to let those things hold me back from success. I focused on where I knew I would stand out and organized my thoughts into the ten main points below:

 

  • Be on time. For any meetings or working sessions that I was a part of, I made it a habit to be a couple of minutes early. There were life events or uncontrollable circumstances that prevented me from this 100% of the time, but those were one-off occurrences. Generally speaking, I was known to be early and start meetings on time. This showed I was organized and respected the time of others. Additionally, being on time also meant projects and tasks were completed by the time I said they would be. If there were issues that prevented me from hitting a time goal, I would speak up and inform the respective stakeholders in advance so they were aware.

 

  • Take ownership. Anytime a project or task was assigned to me, nobody had to worry or consistently follow up on its completion. I communicated statuses and any obstacles or issues that might impact the final result. This was evident no matter how small the task was. Early on in my career, I was responsible for member service requests. Each interaction was a mini-project to ensure the member got the service they required. Taking ownership of all of my projects and tasks helped build trust with my boss and colleagues. It showed I was ready to handle larger projects and more responsibilities because I excelled with the smaller ones.

 

  • Be flexible. My ability to be flexible about almost anything shined through. My role in one project may not have been the exact same as another one. Priorities and objectives often changed. My colleagues all had different and unique personalities. In some projects, I was the dominant personality when others did not play that role. In other projects, I was the more analytical one when I realized others were observably dominant. Through it all, I remained flexible. I was known as the go-to person for just about anything.

 

  • Nothing underneath me. My first project was a stepping stone to the next one. When I was starting my career, I admittedly was a “yes” person. They could have given me a stamp with “Yes” for my forehead! Before anyone even finished their thought, I said “Yes!”. This helped me get exposure to every single area of my organization and build relationships. Within a short period of time, I could tell you the purpose of each department and why they were necessary for the organization to function properly. I am not saying I could run the department, but I had functional knowledge of their work and what made them tick. I don’t want to give the wrong impression here. As I advanced more in my career, I didn’t have the time to say yes to everything. I learned how to say “no” as my career became more mature. However, when I first started, I wanted exposure to everything and I wanted to show I can handle it.

 

  • Recognize and praise others. I don’t remember accomplishing a goal due to my efforts alone. There were always other people involved. Lots of time in discussions was spent with team members to ensure we were doing the right things. I always made it a point to praise publicly and privately where it was legitimately due. I saw first hand all the hard work that my colleagues put into their daily activities and wanted those efforts recognized. Any time I got praise for doing something, it was only because I had a great team of people supporting me.

 

Advertisement

 

  • My first project. I tried my best to stay excited and eager to learn and do more. When I was just a part-time employee trying to make a name for myself, I was hungry for anything that came across my desk. I started to treat everything like my very first project. I would ask lots of questions, show willingness to go above and beyond, seek help where I need it, and work with others. Every project after the first one was treated like my first one. This is much more difficult than it sounds because at times, work did become mundane and repetitive. I had to make a conscious effort to see the bigger picture and maintain my level of excitement.

 

  • Open to criticism. I had an open mind if someone gave me constructive criticism. This helped me get better as a professional and build my skills. I actively sought out criticism to ensure I produced things of value to the organization. Long tenured employees, managers, and executives all have different insights into different areas. Their advice helped me see things from a different perspective and ensure I took that into consideration moving forward.

 

  • Be courteous. I cannot think of any point where insulting someone, yelling, making sexually suggestive comments, touching inappropriately, or being plain rude was ever welcomed. I paid attention to my tone of voice and ensured my dialogue was objective to the matter at hand. Disagreements are common and objectively addressing them should be the goal, not trying to tear the other person down. Learning about culture, gender, age, race, religion, or any other characteristic that makes us unique, helped me get to the next level of relationship building. Showing common courtesy, being generally kind, and showing basic respect for someone  should not require a whole training initiative.

 

  • Work life integration. I did not seek work life “balance”; where I strictly worked between certain hours and then I strictly lived my personal life during certain hours. My job was part of an overall healthy life; and in order to continue having a healthy life, I needed my job. Sometimes, my best work came from putting in a few hours on a Sunday with some music in the background. Sometimes, I had to handle a personal emergency at the office that took time away from my work. I didn’t get stressed out about those things because I knew the work would get finished and my personal commitments wouldn’t be sacrificed. If responding to an email on a Saturday helped my colleague move on, I did not hesitate to do it.

 

  •  Always learning. I was always confident I could learn anything that I needed to help in my career. Today, I see the younger generation spend hours upon hours on social media, video games, and YouTube. I challenge anyone to take any topic in the world you want to learn. Spend one to two hours daily focusing on and researching that topic. The same focus you would give to having fun. Come back in a year and tell me that you are unable to explain the general and functional information of that topic. I dare you! I was amazed at how much I learned by giving it enough focus and time and you will be too.

 

In conclusion, these ten things made such a positive impact in my career and I know they will do the same for you.

BATimes_May31_2023

The Dilemma of Test Scripts

Mention software testing to 10 people in IT and you will get several different responses.

“That’s what QA is for.”

“Unit testing covers what we need.”

“What do we need to test for? The application works fine!”

“We’re Agile. We don’t need to test.”

“The client’s not banging down my door – so all is good.”

“No, we can’t release to UAT yet. I’m only halfway through writing the test scripts.”

“I don’t have time to test.”

“I don’t know how to test this. I’ll need some guidelines.”

“That’s not in the budget.”

If you work as a BA in an IT department, you have likely heard all of these retorts – sometimes even from those who should know better.

 

It is also a trigger that can lead down a deep rabbit hole of shortcuts and excuses, with the ultimate result being sloppy code, error-prone software, and possibly tons of rework post-release. Not only impacting you and your team, but also potentially leaving your company with very unhappy customers.

Software testing has several variations, all meant to ensure that the customer is happy in the end and that fewer issues, or bugs come back to haunt the product development team. Unit testing and smoke-testing are two of the most common types of testing. Unit testing is ordinarily done by the engineer as a part of coding and is meant to test the individual functions of the various components of the specific software. Smoke-testing is done after the release of the code into production. It serves as a means to make sure that nothing has been broken by the new code. Another critical form of testing is called regression testing, which focuses on how the new code works with the existing code. Regression testing requires additional planning and visibility of enhancements between releases.

At a bare minimum, unit testing and smoke-testing are essential. They are cheap and easy and require a minimal amount of effort.

 

The real testing, however, comes in the form of functional tests and acceptance tests. This is how you connect the code that is created by the engineers with the business needs of the customers and the real-life use of the application.

Functional tests validate that the newly designed process aligns with the requirements that were provided to the development team. Functional testing is best performed by either the business analyst or the QA analyst. A distinct benefit is gained here when functional tests are designed and completed by someone who is familiar with both the application and the enhancement requirements. Here is a tip: well written requirements and an experienced QA analyst are your best friend for stellar results!

Acceptance tests (also known as User Acceptance Testing or UAT) validate that the finished product aligns with the needs of the business user. This type of testing allows the end user to touch-and-feel the new process to make sure that it will correctly address the defined business need. An end user is also looking to make sure that the workflow is not made worse. At the end of the day, the user still has a job to do!

 

Advertisement

 

A well-designed set of test scripts is the most efficient way to track results, and to facilitate tracing the functionality back to the requirements. A plethora of applications exist that do this for you! Many of these applications can also run the test scripts in an automated fashion, which works great for regression testing. If I have access to an experienced QA analyst, I leave the decision up to that person. I simply provide rock-solid requirements and expectations and make myself available for questions.

That said, I am a big advocate of DIY.

If I am running functional tests myself, I create test scripts the old-fashioned way: Excel spreadsheets. The perception is that this takes too much time. Yes. It can be tedious. However, if you consider that good test scripts can also be used for system and user documentation – a bonus for start-ups – it is an essential task, regardless of the effort. They can be maintained and re-used.

Put your user hat on and give it a try!

 

Begin with a few basic columns:

Who is the user? What role is the user filling while performing this task?

What is being tested? Describe the function in simple terms.

What are the exact steps to get the desired result?

What is supposed to happen when the steps are completed?

What actually happened when the steps were completed? Ideally, you would want this to be the same as what was supposed to happen. Many times, it is not.

Did the test Pass or Fail?

 

Add more context for tracking and tracing back to the requirements, like test IDs for each test and date tracking to facilitate repeat testing.  Add a column for additional comments so that the person who is running through the tests can add additional observations about what was experienced during the test.

 

 

In short, product quality drives customer satisfaction. Complete and consistent testing and retesting is one of the best ways to drive customer satisfaction with new products and product enhancements. It’s well worth your time and effort.

Happy testing!

Impact of Artificial Intelligence on Business Analysts and BA Jobs

Artificial Intelligence is no longer a buzzword, and it has been making waves in the tech industry. We are experiencing AI in our day-to-day life in the form of chatbots, Voice assistants in serving customers’ requests, forecasting market trends, detecting possible future ailments, and much more. In recent years, businesses have begun adopting AI to improve their operations and gain a competitive edge. But what does this mean for business analysts and BA jobs? With the rise of AI, will Business Analysts become obsolete, or will it create new opportunities? Let’s dive into how artificial intelligence affects business analysis and explore what the future holds for those in this field.

If you are a business analyst, you need to be skilled to leverage these technologies as an added advantage to your capabilities to deliver continued value to your organization.

So, are you geared to make the most of it or see it as a threat, or are apprehensive of losing your job to AI?

AI is your new superpower

As a business analyst, you have access to a wealth of data to help you make better decisions for your company. But what if you could tap into the power of artificial intelligence (AI) to supercharge your decision-making process?

With AI-powered business analytics tools, you can get insights that would otherwise be hidden in your data. For example, you can use predictive analytics to identify trends and patterns in your data and then use those insights to make better decisions about where to invest your resources.

AI can also help you automate repetitive tasks so that you can focus on more strategic work. For example, you can use natural language processing (NLP) to automatically generate reports from unstructured data sources like social media or customer feedback surveys. Using these opportunities helps us converse with customers about new possibilities.

In short, AI is your superpower when it comes to making better decisions for your business. So why not put AI to work for you?

 

Use AI to have more control over your time and use it more efficiently –

Let AI do all your routine, monotonous/repetitive jobs that free up more time and energy for Business Analysts.

Artificial Intelligence (AI) is increasingly being used to automate low-level tasks, freeing time and energy for Business Analysts. This allows Business Analysts to focus on more strategic tasks, such as identifying new opportunities, analyzing data, and improving processes. As AI continues to evolve, it is expected that even more mundane tasks will be automated, further freeing up time for Business Analysts to add value to their organizations. Let the easy and monotonous tasks be taken up by AI, leaving the complex and the more challenging tasks to humans. Having said that, it requires us to grow and sharpen our skills.

 

BAs add significant value to the organization with their cognitive abilities

BAs add significant value to the organization in many ways that AI can’t take up.

They:

  • Perform a pivotal role in bridging the gap between business and IT.
  • Help/collaborate with stakeholders in prioritizing the requirements, helping them refine the requirements, and eliciting them using various techniques.
  • Influence/assist stakeholders in moving towards the unified project goal by communicating effectively.
  • They understand the business domain and processes and translate them into technical requirements.
  • They often apply out of the box solution approaches to solve business problems where a straightforward solution may not be available.

All these skills are essential for the success of any project or organization but cannot be replaced by AI.

Here is a detailed analysis of skills/tasks that currently are not possible to be taken up by AI.

 

Advertisement

 

Problem-solving

BAs help in Problem-solving – For impediments faced in the process or by the team:

Artificial intelligence has altered the role of business analysts and BA jobs. In the past, BAs were responsible for gathering requirements and documenting them. However, with the advent of AI, business analysts now need to be able to solve problems that may arise during the process or by the team.

This is where AI can be beneficial. With its ability to identify patterns and correlations, AI can help business analysts understand why specific problems are occurring and how they can be solved. Additionally, AI can also help BAs predict future problems that may arise and recommend solutions accordingly. As a result, BAs are now able to provide more value to their organizations by helping to solve complex problems.

 

Out of box thinking

Organizations are under constant pressure to do more with less. As a result, they need their employees to be creative and come up with innovative solutions to problems. This is where out-of-the-box thinking comes in.

Business analysts are in a unique position to help with this. They are trained to think critically and creatively, and they have the analytical skills to back up their ideas. BAs can help organizations see problems from different perspectives and come up with new solutions that they may not have considered before.

AI is only going to increase the demand for out-of-the-box thinking. As AI capabilities continue to grow, businesses will need employees who can think outside the box to keep up. BAs who can provide this critical thinking will be in high demand.

 

Critical decision making

BAs help in coming up with the best possible solution from the various alternatives.

BAs help organizations to make sense of all the data they collect and to use it to make better decisions. With the help of artificial intelligence (AI), BAs can now do even more to improve decision-making. AI can help BAs to identify patterns and correlations that they might not be able to see with their human eyes. AI can also help to automate some of the tedious tasks that BAs have to do, such as gathering data from multiple sources. This frees up the BA’s time so that they can focus on more strategic tasks.

AI is also helping BAs to come up with better solutions from the various alternatives available. With AI, BAs can test out different scenarios and see which one is most likely to succeed. This helps organizations to make better decisions and to avoid costly mistakes.

Overall, AI is having a positive impact on the job of the BA. With AI, BAs are able to do their jobs more effectively and efficiently.

 

Stakeholder collaboration –

BAs play a critical role in validating and prioritizing needs.

In any business, it is essential to have a good understanding of what your stakeholders want and need from you. This can be difficult to do without the help of a business analyst. Business analysts are experts in stakeholder collaboration. They can help you validate and prioritize the needs of your stakeholders. This is important because it ensures that you are meeting the needs of your stakeholders and that your business is able to run smoothly.

 

Bridging the gap between tech and users

As the adoption of artificial intelligence (AI) continues to grow in businesses around the world, the role of the business analyst (BA) is evolving. BAs are uniquely positioned to help bridge the gap between technical teams and users, and workshops are one way they can do this.

Workshops help BAs understand the needs of users and translate them into requirements for technical teams. They also help technical teams understand the capabilities of AI and how it can be used to solve business problems. By facilitating communication between these two groups, BAs can ensure that AI is deployed effectively and efficiently.

What’s more, as AI becomes more complex, the need for BAs who can navigate its increasingly murky waters will only grow. With their deep understanding of both business and technology, BAs are essential partners in helping organizations realize the full potential of AI.

 

Data analysis –

Deriving intelligent insights from the data to facilitate business decisions.

A Business Analyst (BA) is responsible for analyzing an organization or business domain and documenting its business or processes or systems, assessing the business model or its integration with technology. They also help in data analysis and derive intelligent insights from the data to facilitate business decisions. Data analysts use statistical techniques to examine data and draw conclusions from it. They help businesses to make better decisions by taking into account a wide range of factors, including cost, time, resources, risk, and objectives. The role of a BA has become even more critical in recent years as organizations strive to become more data-driven in their decision-making.

With the advent of artificial intelligence (AI), there is ample opportunity for BAs to leverage AI technologies to improve their efficiency and effectiveness in data analysis. AI can help BAs to automate repetitive tasks such as data collection and cleansing so that they can focus on more strategic tasks such as identifying trends and patterns in data. AI-powered tools can also help BAs to make better recommendations by providing them with real-time insights based on large volumes of data.

In order to take advantage of these opportunities, BAs need to upskill themselves in AI technologies. There are many online courses and resources available that can help BAs get started with learning about AI.

 

Ethical and responsible use of confidential customer information

As business analysts, we are constantly working with confidential customer information. It is our responsibility to use this information ethically and responsibly.

Here are some ways that we can do this:

  • Be transparent about how we will use the customer information.
  • Get explicit consent from the customer before using their data.
  • Keep the customer information secure and protect it from unauthorized access.
  • Only use the customer information for the purpose it was collected for.
  • Dispose of the customer information securely when we no longer need it.By following these guidelines, we can ensure that we are using confidential customer information in an ethical and responsible manner.

To sum it up, keep your skills chiseled, use your cognitive skills to deliver value, keep your learning on, and leverage technology to keep you in demand.