Skip to main content

Tag: Use Cases

Upskilling Your BA Team

Upskilling Your BA Team

AUTHOR: Virginie Terry

1. This is the way we’ve always done it…

One of the most common barriers to adopting new ways of working is a belief from the long-standing BAs that their delivery or operating models are different from the norm, or that their business stakeholders are unusual, and therefore different BA skills or standards apply. This is particularly true with BAs who have learned their skills on the job: internally and without any formal training. Typically, they will have moved from a different part of the business, and they know the ins and outs of specific departments, including the quirks of their systems. This can manifest itself as skills gaps (e. g. made up notation to model business processes); undertaking tasks which should legitimately sit in other areas (e. g. writing test scripts); or not being effective in their role because they don’t challenge their business stakeholders to work differently when defining to be processes.

These individuals need to understand internal expectations as well as the BA industry standards, and in particular the skills that as a manager you are looking for in new joiners. They need to appreciate that refusing to upskill could put them at a disadvantage in terms of the projects they work on or future career opportunities.

2. I’m looking to retire in a few years, why should I bother?

Not everyone thrives on learning something new and getting out of their comfort zone when they are counting the days until they retire.

As a manager, it’s only worth pushing if there is still time for these individuals to apply new skills before they retire. These BAs need to understand how this will improve or expedite some of the great work that they already do. For example, if you’re looking to get a BA trained on use case diagrams, you can easily demonstrate how much more engaging they are to project stakeholders than Jira tickets or an Excel spreadsheet when it comes to reviewing the outputs of a discovery workshop.

3. My project can’t afford to release me for any training, sorry!

A misconception which comes up time and again is the belief that project teams can’t afford to release their BA(s). The truth is that there is rarely a time in any project when a project or programme manager feels that they can afford not to have their BA(s) around, regardless of the stage of the delivery.

A tough one to win if project teams don’t have enough time to plan it. Give the BAs and project teams plenty of notice – ideally several months, so that the BAs can block the time in their calendars, and the project teams can plan for it. It’s important to show some flexibility and collaborate with programme and project managers, for example by staggering the training dates if multiple BAs work together on the same programme or project, rather than taking them all away on the same day(s)

4. I am too old to learn something new

Not quite the same as the BA who’s retiring soon, in this case we’re looking at BAs who may doubt their ability to learn and apply new techniques, or even have some anxiety about sitting exams because they are out of practice. You may also have a BA who’s just not very academic and really struggles with formal learning and assessment / exam situations.

Getting back into a classroom (albeit a virtual classroom) can be daunting. It is the manager’s responsibility to provide support and minimise stressors where possible. You should be able to negotiate revision sessions with your training provider in the run up to any assessment, and if not there is always internal support available from BAs who have already completed the training. Reminders about exam techniques and dealing with exam nerves are useful – as well as being honest with your team and sharing your own story. It is very powerful for team members to be aware that their manager may have gone through the same thing, and how they have overcome their own demons.

5. Celebrating success in the right way

It is necessary to find the right balance between celebrating the team’s successes, which is entirely legitimate and appropriate, and not inadvertently making people feel any pressure or “less than” if they haven’t taken the exams yet or they have failed.

Ultimately, as with so many situations, the key to success is for BAs to realise what’s in it for them. And in the vast majority of cases, once get a few people over the line – once they are, they become your strongest advocates and allies for change.

The Incredible Expanding Requirement

The Incredible Expanding Requirement

A simple requirement statement might conceal much detail that eventually must be discovered and addressed.

Image by kjpargeter on Freepik

Some requirements are like icebergs: The portion that you see initially is only a small fraction of the whole thing. Whether it’s represented as text—such as a single functional or nonfunctional requirement statement, a feature summary description, or a user story—or visually in the form of an analysis model, there could be far more to it than first appears. Requirements analysis involves digging below the surface of a presented requirement to understand its full scope, complexity, and implications.

Let’s consider a simple, common nonfunctional requirement: “Only authorized users may access system services.” That security requirement could have originated from a company policy, government regulation, or other business rule. Can you just hand that requirement to a developer, or maybe write it in the form of a user story and add it to the product backlog? I don’t think so. Peeling away the layers shows that that one requirement statement can expand enormously, raising many questions and spawning many child requirements along the way.

This raises the question of how much detail to document for an unrefined requirement versus leaving it in the hands of the developer to process as they see fit. In other words, who do you want to make all the decisions associated with a complex requirement, and when? Considering that question will help you manage the transition from requirements to design.

If you want an initial high-level requirement implemented in a specific way, the business analyst should elaborate it into the appropriate level of detail and precision. That elaboration could impose design constraints on the developer, albeit for good and thoughtful reasons. On the other hand, if you’re okay with the developer having the final say on the functionality and user experience details (preferably with feedback from others on design documentation, prototypes, or screen sketches), then just pass the higher-level requirement along for implementation.

Looking Below the Surface

Consider some of the questions you’d have to answer if you were the developer asked to implement our one-sentence security requirement. It’s unlikely that you’d have all the answers yourself. As you study the requirement, you’d have to make up those answers, research policy standards, or consult with others to agree on how to resolve each issue. That’s what business analysis is all about. Let’s see how quickly an exploration of this single requirement statement expands into many detailed requirements.

First, we’ll need a clear definition of exactly what an “authorized user” is and just what system services cannot be accessed unless a user is authorized. Do different parts of the system require different privilege levels or access credentials?

How should each user be uniquely identified? With a login name, an email address, using a third-party account (like Google, Apple, Facebook, or X), or something else? Will the user ID be assigned by a sys admin or user-selected? What are the rules for the user ID: minimum and maximum length, allowed characters, and case sensitivity? What happens if the user selects a user ID that’s already in use?

Next, what is the primary user authentication mechanism? We have numerous choices, including password, passkey, PIN, and biometrics of various kinds. Let’s just think about the venerable password for now. Here are some questions that come to mind regarding passwords:

  • What are the rules for the password: minimum and maximum number of characters; allowed, prohibited, and required; characters, case sensitivity; pattern restrictions (such as no more than two instances of the same character in sequence); required patterns (such as at least one each of upper- and lowercase letters, numbers, and symbols)?
  • Must the user re-enter the same password in a separate field during creation to verify it? If so, what happens if the two entered passwords don’t match?
  • Can the user toggle the visibility of the entered password on and off, either during creation or during logins?
  • How is the password masked in the entry field? With asterisks or dots? One symbol per entered character or a random number of symbols to conceal the password length from an onlooker?
  • What feedback will the system provide if a login attempt fails?
  • Is the user blocked after too many unsuccessful login attempts? If so, how many tries do they get?
  • If the user’s account is locked after too many failed login attempts, how long does the account remain locked? How can the user unlock it?
  • What happens if the user forgets their login ID or password? What recovery method is used? I can’t get into my original YouTube account because I’ve long since forgotten the password, and the phone number on the account cannot receive texts. Google offers me no other identity verification options.
  • Must the user change their password periodically? If so, how often? Are there restrictions on what the new password can be, such as not reusing any of the previous N passwords?
  • Can the user define a personal identification number (PIN) as a shortcut for the password, as on a Windows PC? If so, what are the allowable characters and the minimum and maximum length of the PIN?

These are some of the issues associated with specifying a security requirement for just a simple password mechanism. You can see how the answers to those questions lead to more and more functional requirements to satisfy the nonfunctional security requirement. But the expansion can get much worse.

The Many Modes of MFA

If your project’s decision makers want better security than a password provides, you’ll explore multifactor authentication (MFA) options. You’ll need to choose from numerous options for both MFA techniques and their implementation details. Start by deciding what types of MFA the system should enable to provide the desired security level. Options include:

  • Sending a one-time code that the user must enter to verify their identity
  • Sending an email containing a one-time login link
  • Biometrics, such as fingerprint, facial recognition, voice ID, and iris or retinal scan
  • A physical security token
  • Using an authenticator app, perhaps on a second device

Here are a few more general questions:

  • How many of these MFA options should you make available to the user?
  • If more than one, can the user select their default preference to use initially for each login attempt? Can they change that default?
  • How will the user enable and disable MFA on their account?
  • If for some reason the user can’t employ their initial method (such as not having access to the device with the authenticator app), can they select another method for that session?
  • Will there be some other backup action, such as contacting customer support, in case none of these MFA methods work for the user?

Let’s take a closer look at just the technique of sending the user a one-time code. Contemplate these questions:

  • What options will you provide for sending the code: text message, e-mail, or phone call? Will the user have more than one option available?
  • If text message or phone call, can the user save more than one phone number in their application’s profile? Can they specify the default and select the number to use for each session? Can they change or delete a saved number or change which is the default?
  • How many characters are in the one-time code and what are the valid characters?
  • How long is the one-time code good for? If it’s limited, should the application display a countdown timer? Can the user request to have the code re-sent? If so, is the same code sent again or a new code? What happens if the user enters the one-time code after the time-out period?
  • What happens if this secondary authentication attempt fails? Is the entire login session terminated, or can they try the MFA again? How many tries does the user get at the MFA action? If it’s limited, do attempts using different methods all count toward the limit?
  • Can the user opt to have their authenticated device and login recognized for some period of time so they won’t have to re-authenticate for each session? If so, how long is that period? Where should that information be stored? I use some apps that recognize my device even if I restart my browser, while others lose my remember-me setting whenever I clear the browser cookies.

I’m sure there’s even more to it than this, but you get the picture. Drilling into the particulars of an initial, concise requirement statement often opens a sizeable can of worms. The answers to the resultant questions lead to an explosion into more and more requirements. This fact is true whether the exploration is performed by a business analyst during requirements specification or by a developer who’s been tasked to write the user authentication code. The original requirement isn’t actually growing, so this process isn’t changing the project’s scope. It’s merely revealing the true scope.

The good news is that if you can craft a well-thought-out set of requirements for a complex function like user authentication, you can likely reuse them in multiple applications. At the least, they should provide an excellent starting point.

Beware the Blast

I’ve used a common nonfunctional requirement to illustrate how much complexity can hide beneath the tip of that requirement iceberg. The same can apply to functional requirements and product features, of course.

One of my consulting clients held a large workshop to gather requirement ideas for a new flagship product. One of the requirements stated, “The product shall respond to editing directives entered by voice.” This was at a time before speech recognition capabilities were built into all of our devices. That one simple requirement statement looked to be no bigger or smaller than all of the many others in the set. However, you can guess how large the requirements explosion would be when someone looked into everything involved with the details of that speech recognition feature.

Understanding the true scope of a requirement so your team can estimate and plan for its design and implementation often requires a fair amount of exploration. During that exploration, you can set the priorities of the various child requirements, perhaps deferring some functionality to later development iterations and maybe never implementing others. That thinking process is less painful than encountering one additional, unexpected need after another and continually revising the product.

======

Karl Wiegers is the author of Software Requirements Essentials (with Candase Hokanson), Software Requirements (with Joy Beatty), Software Development Pearls, The Thoughtless Design of Everyday Things, Successful Business Analysis Consulting, and numerous other books.

 

BATimes_Sep11_2024

The Mirage of AI as a Cure-All: How to Ground Executive Enthusiasm in Realistic Outcomes

In today’s fast-paced business environment, artificial intelligence (AI) is often heralded as a panacea for a wide range of organizational challenges. Whether it’s optimizing supply chains, improving customer service, or enhancing decision-making processes, AI promises to revolutionize how businesses operate. However, as any seasoned project manager or business analyst knows, the reality is far more nuanced.

Many executives, driven by the latest headlines or industry trends—often referred to as “managing-by-magazine”—may come to you with the next “big idea” for an AI project. While their enthusiasm is commendable, it can also lead to unrealistic expectations and poorly defined projects that fail to deliver the promised results.

 

The Problem with AI Hype

The marketing surrounding AI often paints it as a silver bullet capable of solving any business problem. This can create a disconnect between what executives expect and what AI can realistically achieve. Without a clear understanding of AI’s limitations and the specific problems it can solve, organizations risk investing in projects that deliver little to no return on investment (ROI).

As a project manager or business analyst, your role is to bridge the gap between executive enthusiasm and practical outcomes. This involves not only understanding AI technology but also being able to communicate its potential and limitations in a way that resonates with decision-makers.

 

Start with the Use Case

The first step in any AI project should be to thoroughly discuss the potential use cases. What specific problem is the AI solution intended to solve? How will success be measured? By framing the conversation around use cases, you can help executives focus on the practical applications of AI rather than getting swept up in the hype.

For example, if an executive is excited about using AI to improve customer service, you might start by discussing how AI could be used to automate routine inquiries, allowing human agents to focus on more complex issues. From there, you can explore the potential ROI, such as reduced call times or improved customer satisfaction scores.

 

Identify Specific Deliverables

Once the use case is clear, the next step is to identify specific deliverables. What tangible outcomes will the project produce? These could be anything from a working prototype of an AI-powered chatbot to a detailed report on how AI can be integrated into existing workflows.

By focusing on specific deliverables, you can help manage executive expectations and ensure that the project remains grounded in reality. This also makes it easier to track progress and measure success, as you will have clear milestones to work towards.

 

ROI: The Bottom Line

One of the most critical aspects of any AI project is identifying the potential ROI. This involves not only estimating the financial return but also considering the broader impact on the organization. Will the AI solution improve efficiency? Reduce costs? Enhance the customer experience?

ROI calculations should be revisited regularly throughout the project lifecycle. As new information becomes available, it’s important to reassess the potential benefits and adjust the project scope as needed. This iterative approach ensures that the project remains aligned with organizational goals and delivers real value.

 

Refine Through Requirements Gathering

Even with a clear use case, specific deliverables, and a well-defined ROI, it’s essential to continually refine the project scope through requirements gathering sessions. These sessions allow you to gather input from various stakeholders, identify potential challenges, and ensure that the project remains on track.

During these sessions, it’s important to ask probing questions to get to the heart of the matter. What are the underlying business needs? How will the AI solution integrate with existing systems? What data will be required, and how will it be managed? By addressing these questions early on, you can prevent scope creep and ensure that the project stays focused on its core objectives.

 

Advertisement

 

The Power of Business Process Mapping (BPM)

One highly effective tool for refining project scope and ensuring alignment with business objectives is Business Process Mapping (BPM). BPM is a visual representation of an organization’s workflows and processes, and it can be instrumental in highlighting inefficiencies, redundancies, and gaps within current operations.

Before diving into an AI implementation, BPM can help you and your stakeholders gain a clear understanding of how work is currently being done. By mapping out existing processes, you can identify where AI might be most beneficial, as well as areas that may need improvement before AI can be effectively integrated.

For instance, if a process map reveals that a significant amount of time is spent on manual data entry, this could be a prime area for AI automation. Conversely, if a process is already highly optimized, it might not be the best candidate for AI enhancement, helping you avoid misallocation of resources.

BPM also serves as a communication tool, providing a common language for discussing process improvements. It enables all stakeholders to visualize where changes will occur, what the expected outcomes are, and how the AI solution will fit into the broader organizational landscape. This transparency can help prevent misunderstandings and ensure that everyone is on the same page regarding the project’s goals and expectations.

 

Conclusion: Turning AI Hype into Real Results

AI has the potential to transform businesses, but it’s not a one-size-fits-all solution. By taking a thoughtful, measured approach to AI projects, you can help your organization avoid the pitfalls of “managing-by-magazine” and achieve real, tangible results.

The key to success lies in grounding executive enthusiasm in practical outcomes. This involves thoroughly discussing use cases, identifying specific deliverables, calculating potential ROI, and continually refining the project scope through requirements gathering sessions. Additionally, leveraging tools like Business Process Mapping can provide valuable insights into existing workflows, highlighting areas where AI can be most effective and ensuring that the project delivers real value.

By following this process, you can ensure that your AI projects are not only aligned with organizational goals but also contribute to the long-term success of your organization.

BATimes_Jun8_2024

Key Documentation Prepared by Business Analysts

Documentation is the core part of the business analysis process that provides clarity, standards, and process details that help organizations in decision-making. The documentation provides information about the guidelines, requirements specifications, roadmaps, communications, blueprints, and solutions that are crucial for the execution of the project.

Business analysts create various documents to translate complex requirements into accessible language that can be understood both by the technical and non-technical staff of the team. Business analysts bridge the gap between the business stakeholders and the technical team by creating various documentation that provides clear, concise information on the problem statement, business objectives, key requirements, restrictions, exclusions, and solutions that help in the alignment of the team.

A well-crafted document by the business analyst helps the organization secure the budget required for the execution of the project and forecast any risks during the implementation of the project. Documentation also helps to align the project with the overall organization goal and describes the value added to the organization goal by the execution of the project.

 

Key Documentation Prepared by The Business Analyst

  1. Business Requirements Document (BRD):

The business requirements document is one of the most common documents that is prepared by a business analyst. BRD captures the big picture of the project and stakeholders’ business needs. It provides detailed information on the project goals, objectives, and approved solutions, along with the key deliverables that define the scope and associated benefits of the project’s execution.

Although the fields in the BRD change from organization to organization, here are the key fields in the BRD document:

  • Project details

The project details section includes information such as project name, project number (if applicable), organization department details, business sponsor details, key stakeholder information, project manager, architects, and details of the technical team members working on the project.

  • Project Overview

The project overview provides high-level project objectives and their benefits. This is the section one would read to get the complete summary of the project.

  • Project scope and out-of-scope items

The project scope lists the deliverables of the project; this helps both business stakeholders and the technical team be on the same page and provides clarity on requirements.

Project out-of-scope lists all the items that are identified as outside of the project scope. Identifying the out-of-scope during the initiation of the project helps to avoid any scope creep during the execution of the project.

  • Assumptions

The assumptions section provides a complete list of assumptions relative to the scope of work. These assumptions are agreed upon and approved by the business stakeholders.

  • Current and future state business processes

The current state of the of the business process depicts a snapshot of the current state of the organization, and the future state highlights the deliverables of the project.

This section helps to have a side-by-side comparison of the enhanced functionality that will be achieved by the project.

  • Business requirement

The business requirement is the main section of the BRD. This section lists all the action items that are required to achieve the project scope.

Along with the action items, it is important to assign priority to each item, as it helps the technical team identify which task they need to pick first.

For projects where the implementation of the business requirements is divided into multiple releases, it is important to include release details in the business requirements section.

  • Business rules

The business rules section consists of all the project-relevant business rules that were agreed upon and approved by the stakeholders. Business rules usually trace back to business requirements.

  • Project risks

The project risks section includes all the risks identified and mitigation measures for the risks. Identifying the risks ahead helps the team focus on their tasks and reduces uncertainty during the execution of the project. Identifying risks earlier also helps to make better business decisions.

  • Cost-benefit analysis

Cost-benefit analysis is the last section of the BRD. In this section, you describe how the project objectives will make a profit for the organization and estimate the ROI that can be achieved with the execution of the project.

 

Advertisement

 

  1. Functional Requirements Document (FRD):

The Functional Requirements document provides information about the business problem and approved solutions for the problem. FRD is the contract between the business and the technical team to deliver the accepted solution. It provides information about key functionality that a solution system needs to have and the performance of the system. FRD captures all the nitty-gritty information about the solution product.

The FRD document is different from the BRD , as FRD focuses more on the nitty-gritty details of the solution and BRD focuses on the broader view of the overall project.

The style and fields of the FRD document change from project to project. Here are the key fields of the FRD document:

  • Project details

The Project Details section includes detailed information about the project, such as project name, project unique number, organization department details, business sponsor details, key stakeholder information, project manager, architects, and details of the technical team members working on the project.

  • Project Description

An overview of the project, its benefits, and the approved solution. This is the section one would read to get a complete overview of the project.

  • Project Background

The project background describes the problem statement of the project and the purpose of the project.

  • Project scope and out-of-scope items

The project scope lists all the deliverables of the project, including the technical details of the solution system. This section helps both business stakeholders and the technical team be on the same page and provides clarity on requirements.

Project out-of-scope lists all the items that are identified as outside of the project scope. Identifying the out-of-scope during the initiation of the project helps to avoid any scope creep during the execution of the project.

  • Assumptions

The assumptions section provides a complete list of assumptions relative to the scope of work. These assumptions are agreed upon and approved by the business stakeholders.

  • Functional requirements

The functional requirements section describes what the system must do. Functional requirements must be drafted in a way that provides complete information about the business needs and specifications needed in the solution system.

  • Operational requirements

The operation requirements section describes how the system must operate, i.e., how fast the system should respond, how many responses the system needs to provide in the given time, etc.

  • Requirement Traceability Matrix

The requirement traceability matrix is described in detail in the section below.

The requirement traceability matrix is used to track the implementation of the functional requirements. The RTM is updated throughout the project to show the progress made in the implementation of the functional requirements.

  • Glossary

List all the business terms and their definitions.

 

  1. Non-Functional Requirements Document

The non-functional requirements document defines how the system must behave. This section is crucial for the execution of the project; it describes the capabilities of the system operation and its constraints. Non-functional requirements provide information about system users, scalability, operation, hardware and software, performance, retention and capacity, accessibility, and security.

The solution system can still operate by just executing the functional requirements, but it might not meet all the business expectations in terms of security, performance, scalability, etc.

 

Below are the fields that are going to be part of the Non-Functional Requirements document:

  • Security

Security is the most important section of the non-functional requirements document. This section captures all the security guidance that needs to be incorporated by the project execution team during the implementation of the project. It captures security architecture guidance, authentication, data security, risk management, and technology development guidance.

  • Users

This section provides information about the business expectations for the number of users that will use the system. And a number of concurrent users that the system can support without letting the system performance degrade.

  • Scalability

This section captures business expectations for the data volume that the system must support. It also captures the volume that the system can support during peak and non-peak times.

  • Operational

The operational section is different from organization to organization; this is the section that captures the Tier 1, Tier 2, Tier 3… (Severity 1, Severity 2, Severity 3…) incidents that arise and the action plan to resolve the incidents. Based on the severity of the incident, a recovery strategy is defined to get the system back up and running.

  • Hardware and software

This section includes information about any new hardware components required for the execution of the project and the specifications of the hardware components.

It also captures any new software installation or software configuration required for the completion of the project.

  • Performance

The performance section answers questions such as how fast the system needs to perform. What should be the response time of the system?

  • Retention and capacity

The retention and capacity section captures data types that need to be stored in the database and the data retention time frame required for the data. It also talks about the capacity of the database and the various logs that will be available.

  • Accessibility

This section captures information about who can access the system and the minimum requirements for accessing it.

 

 

  1. Requirement Traceability Matrix

The Requirement Traceability Matrix is the document used during the implementation of the project to trace the requirements to its test cases and further to any defects. The main purpose of this document is to prove that all the requirements have been successfully executed and tested by the project execution team.

The requirement The traceability matrix generally consists of the following fields:

  • Requirement Number

The requirement number is the business requirement or the functional requirement number that is captured in either the BRD or FRD document based on organization standards. All the requirements for the project are listed in this column.

  • Requirement description

A brief description of the requirement.

  • Test case number

The test case number is the unique number used to identify the test case for a particular requirement.

  • Testcase description

A brief description of the test case and its scenarios.

  • Test execution result

This section captures if the test case was a ‘Pass’ or Fail’ during the execution of the test case.

  • Defect number

If the test case execution fails, then a corresponding defect is created, and this section captures the defect’s unique number.

  • Defect Status

This section is used to capture defect status such as ‘Open’ or ‘Complete’. This helps to know if the defect was successfully fixed and tested.

 

Conclusion

Throughout this paper, we have discussed various documents prepared by a business analyst that play a crucial role in the project’s success, driving communication and streamlining the process. From the initiation of the project to the implementation and final deployment of the product, these key documents guide the team through the project lifecycle and ensure the team is aligned with business objectives at every step of the project.

BATimes_Mar7_2024

Demystifying MVPs, Prototypes and Others in the BA Landscape

Let’s get some confusion out of the way. There are many different concepts and related acronyms that aren’t always used in the best way. Let’s try to clarify them.

Terms like MVP (Minimum Viable Product), MMF (Minimum Marketable Feature), MLP (Minimum Lovable Product), prototype, and proof of concept are all concepts used in product development, but they serve different purposes and have distinct characteristics. Here’s a breakdown of the differences between them:

  1. Prototype:
  • Purpose: A prototype is a preliminary version of a product used for design, testing, and demonstration purposes.
  • Focus: It primarily focuses on illustrating the product’s design, user interface, and user interactions.
  • Development Stage: Prototypes are created early in the product development process to visualize ideas and concepts before full-scale development begins.

 

      2. Proof of Concept (PoC):

  • Purpose: A proof of concept is a small-scale project or experiment designed to verify the feasibility of a particular technology, concept, or approach.
  • Focus: It concentrates on demonstrating that a specific idea or technology can work in a real-world scenario.
  • Development Stage: PoCs are often done at the very beginning of a project to assess technical feasibility.

     

     3. Minimum Viable Product (MVP):

  • Purpose: An MVP is the most basic version of a product that contains just enough delivery work to satisfy early customers and gather feedback for further development.
  • Focus: It focuses on delivering core functionality to test the product’s intended value to the customers.
  • Development Stage: MVP comes after the idea and concept but before extensive development.
  • Goal: The primary goal is to validate assumptions and learn from user feedback with minimal development effort.

 

     4. Minimum Marketable Feature (MMF):

  • Purpose: MMF is a subset of features within a product that is sufficient to make it marketable to a specific target audience.
  • Focus: It concentrates on delivering features that are essential to meet the needs of early adopters and generate sales or user adoption.
  • Development Stage: MMF typically follows the MVP phase, where you refine the product based on initial feedback and prioritize features for marketability.

 

     5. Minimum Lovable Product (MLP):

  • Purpose: MLP aims to create a version of the product that not only satisfies basic needs but also elicits an emotional response from users.
  • Focus: It goes beyond functionality to provide a delightful user experience and build strong user loyalty.
  • Development Stage: MLP often follows the MVP and MMF stages and is focused on making the product more appealing and engaging.

 

In summary, while MVP, MMF, and MLP are related to the development and release of a product, each serves a different purpose in terms of features, user experience, and market readiness. Prototypes and proof of concepts, on the other hand, are more focused on testing and validating ideas and technologies before committing to full development. In IIBA’s Guide to Product Ownership Analysis (POA®), the concepts of MVP, MMF, and Minimal Marketable Release (MMR) and Minimal Marketable Product (MMP) are introduced in terms of decision-making on what to build. The figure below is from the POA Guide and orders these four concepts. To know more about MVP with PoC and prototyping, check out a great article (with a video interview) with Fabricio Laguna (“The Brazilian BA”) and Ryland Leyton here.

Fig. 2: MVP, MMF, MMP, and MMR in the POA Guide

 

Advertisement

 

Business analysis Behind Proof of Concept (PoC)

We may use a PoC when the goal is to make a very small experiment around a business idea, from which we need to assess its feasibility.

A well-known way to explore ideas in an early phase of design is by conducting Design Sprints.

Business analysis work within this process is of extreme importance. First of all, a BA professional may use their facilitation skills to facilitate the entire workshop. When framing the BA scope to the ideation process, their work starts when applying the “How Might We” technique. If you want to know more about the “How Might We” technique, you can check it out here.

 

After ideating a range of “How Might We?’s, the BA work includes facilitating the following workshops, from which the ideas are refined until a (possibly very bad) prototype is built and tested with users. BAs are usually comfortable with conducting the tests. At the end, they gather the insights from the tests and assess the PoC.

 

Business Analysis Behind MVP

When planning to build an MVP, don’t forget you’re targeting and validating if a business idea, through a product, has value for customers that you believe it has. However, before investing in a solid product, the mindset is that you’re making the least effort possible to have something that technically works.

This means that the work around framing a problem and further elicitation, analysis, modelling, refinements, etc. relies on hypotheses to be validated rather than fixed requirements, allowing for greater flexibility and adaptation to changing customer needs.

 

Business Analysis If You’re Not Targeting an MVP

Sometimes, when building an MVP, it is planned in a way that has a minimum set of features that can be delivered to customers. As already discussed, that’s not an MVP but an MMF instead, so the mindset for building it focuses more on scope modelling to decide which features have to be included.

Also, if the mindset focuses more on delighting customers (sometimes disregarding the business value delivered), that’s not an MVP but an MLP instead. The BA work focuses more on user research, interviews, and partnering (if existing) with UX/UI professionals. Personas and empathy maps are commonly used techniques.

 

After that, you may define your strategy to test your assumptions. There are different techniques, which depend on the testing context. And such contexts have different approaches to use.

As a BA, we can support decision-making about the technique to choose. But also to help in setting up those tests.