Agile Business Analysis: Getting / Writing Lean Requirements

The Agile Manifesto and Lean Manufacturing Principles have changed the IT landscape. This lecture provides a basic understanding of what these are and why they are important.

Over the past 70 odd years, every study of IT project failures has identified missing and misunderstood requirements as the major contributor. This section explains how Agile and Lean philosophies attempt to solve this seemingly intractable problem.

Cynefin is a concrete, simple yet powerful weapon in your arsenal identifying and dealing with IT project issues. It has proven to be effective in many different settings. You will find it useful in determining which projects are more likely to succeed before you spend a ton of resources. It is also a valuable tool for assessing and prioritizing individual Features, User Stories, and literally any form of expressing a business need.

This lecture demos the real-world application of the Cynefin framework in requirements analysis. We explore how generative AI assists in evaluating requirement statements using Cynefin's Obvious, Complicated, and Complex domains. I present a case study where AI analysis provides valuable insights, logic, and a foundation for engaging discussions. The course highlights how personal knowledge and experience, coupled with AI, can effectively reduce the uncertainties of requirements writing and help make informed decisions, thereby transforming your approach to requirements analysis. A companion resource, the Requirements Template for AI Projects, is included to help you apply these concepts directly to your own work.

When do you perform critical business analysis activities in Lean and Agile approaches and what level of detail do the activities need to achieve?

Eliciting requirements includes the simple process of asking questions but that is just the tip of the iceberg.

The simple act of creating and maintaining an open Question File from the beginning of the project through to the end keeps you abreast of your analysis progress and provides a detailed project history. It allows you to track the progress of your analysis efforts and provides the ideal information for a lessons-learned evaluation.

This lecture presents a detailed demonstration of using the AI tool ChatGPT, demonstrating its application in initiating a new project from scratch.

You will witness firsthand the interaction between AI and a business analyst. We will delve into how to use this AI tool to identify key stakeholders, formulate critical questions, and structure a comprehensive question file.

The lecture begins with an introduction to a new project, highlighting the importance of studying the project's vision statement. Next, it demonstrates how to engage with ChatGPT to generate a list of insightful questions for the various stakeholders involved, such as the Product Owner, Legal Advisor, and more.

By the end of this lecture, you will appreciate how ChatGPT can be a valuable asset in your business analysis toolkit, helping you to streamline the process of project initiation and stakeholder interviews. This will, in turn, allow you to focus on deeper analysis and strategic planning, ultimately leading to the success of your projects.

There are 5 fundamental approaches for eliciting requirements and each has its own pros and cons. In addition, each requires some level of planning, performing, and publishing.

Stakeholder identification is one of the more critical early project activities. Missing critical stakeholders early in the project always leads to missed delivery dates or failed projects.

Delve into the exciting world of stakeholder identification and discover the hidden superpower of AI in this process. Building on a new project assignment and the manager's initial stakeholder recommendations, we explore how ChatGPT can help you extend her list by analyzing the project's vision statement. Not only will you learn to include the usual suspects like Product Owner/Manager, Tech Lead, and Legal, but you will also explore lesser-considered roles, such as UI/UX designer, Marketing Manager, Data Scientist, and others. And the stakeholder exploration doesn't stop within the organization! Discover how to venture out, identifying external stakeholders like users, vendors, dieticians, and even potential investors. Finally, tackle the challenge of ordering or prioritizing the individual interviews. Ready to master stakeholder identification and supercharge your business analysis process? Jump in!

Although you have been communicating with other people since before you learned how to talk, finding the right tone and content of a requirements elicitation conversation can still be challenging.

The core idea of non-verbal communication sound trivial, but experience teaches us that words not spoken often contribute more to accurate understanding than everything the person says.

A comedian once quipped, "Earth would be such a lovely planet if it weren't for all the people." Whether you agree with that comment or not, it obviously is not a great attitude for anyone trying to elicit requirements. We all have issues with certain behaviors of other people, in particular when we are trying to achieve a specific outcome from our interaction. The good news is that there are ways of dealing with every behavior, if you only have time to think about them and plan ahead.

Listening is an art, no doubt. When you are trying to elicit requirements, you need to apply powerful listening techniques to ensure that you get the right information out of the conversation.

There are seven critical criteria for conducting effective requirements gathering conversations.

Before you can start to discuss solutions, you should make sure that you are looking to solve the right problem. This simple problem analysis approach will start you down the right path.

Once you have a list of potential problems, the challenge becomes how to reduce the list to the essential or "real" problems and separate out solutions or symptoms. 

The simple construct called a "User Story" is one of the best modes for expressing stakeholder requirements.

There is immense power in simplicity. Expressing your requirements in simple, single, complete sentences will dramatically increase the number of people who understand what it really means. A good User Story is not a Victorian novel but a trigger for a conversation.

Unless the agile team knows what value a user story delivers, they have no way of determining its relative importance.

Given that projects are restricted by budgets, you should ensure that every request is relevant, meaning in scope, for your project before you spend time delving into details of the request. Your first question should always be, "How does this request contribute to meeting the goal of the project?"

Recognize how ambiguity and subjectivity in requirement statements, user stories, features, etc. impede achieving a common understanding among all audience members.

Identify four common contributors to ambiguity that cause misunderstandings.

Use desk checking, peer reviews, and peer rephrasing to discover hidden ambiguity and subjectivity

Observe the power of ChatGPT in applying the IOW (in other words) technique, a method that encourages paraphrasing requirements to ensure mutual understanding among domain experts, developers, and other stakeholders. By examining how different individuals interpret and paraphrase requirements, you'll gain insights into potential miscommunications and discrepancies, ultimately leading to a clearer set of requirements for project success. We provide practical tips and examples to help you apply the IOW technique in various situations, including Agile environments and with diverse teams. Start mastering requirement clarity today and propel your projects toward success!

Evaluate who is best suited to critique and revise your requirements, user stories, etc.

You've learned to spot ambiguity. Now let's put that skill to work.

This lecture gives you a four-step validation process for any requirement or user story, regardless of whether it came from a stakeholder conversation, your own drafting, or an AI tool. The standard doesn't change based on the source.

The four checks are Traceability, INVEST, the Assumption Hunt, and what Tom calls the Pessimist Test. Together they take roughly ten minutes per story. That sounds like overhead until you run the numbers against what a defective requirement actually costs once it's in development: the wrong thing gets built, QA tests the wrong behavior, the story fails acceptance, and everyone ends up in a retrospective nobody's enjoying. Tom has a name for that sequence too. He calls it the cascade of regret. It's as unpleasant as it sounds.

You'll also see how AI can help run these checks faster without replacing your judgment. AI makes a fast first reader. You still own the result.

Each check is demonstrated against real user stories from a working project, so you'll see exactly what the validation catches and why it matters before anything enters a sprint.

Two resources are available in the course resources section: the Requirement Validation Standalone Prompt Library referenced in this lecture, and the AI Project Requirements Working Template, a structured field guide for documenting and validating requirements on AI projects from vision through acceptance criteria.

In spite of impressions, testing is the most time-consuming activity in the process of delivering IT applications. Unit, Integration/system, and acceptance testing consume about 45% of the total development time. This lecture introduces test-driven development techniques for improving the efficiency of the testing process.

Modern test-driven development approaches rely on test scenarios expressed in the language of Gherkin which relies on Given-When-Then (G-W-T) structures. This lecture provides a basic explanation of the meaning of G-W-T steps.

Test data engineering uses equivalence classes, boundary values, and probable error to limit the number of tests required to achieve confidence that the application works as intended.

Decision tables are a reliable analysis tool for ensuring that an application behaves as intended in all possible situations.  A bonus is that the decision table leads directly into test scenarios.

Assuming you are able to perform basic problem analysis to distinguish symptoms from problems, the symptoms provide a treasure test of test scenarios for acceptance testing.

Commonly considered a development or analysis tool, use cases lay the groundwork for testing as well.

This lesson introduces 2 additional, lesser-known methods for identifying test scenarios that other approaches miss.

Identifying the functions that the application must support or that people need to use the application leads inexorably to test scenarios for unit, integration/system, and ultimately acceptance testing.

Once you have identified the functions the application performs, you need to consider what data each function needs and what data it creates to fine-tune your test scenarios.

Non-Functional Requirements (NFR) are often the cause of IT project failure. It is not enough to know the application does what it should do. The question is does it do it well enough, fast enough, often enough? Learn the most common types of NFR that are often neglected.

Asking the right questions early in the process is key to determining which Non-Functional Requirements your project has to meet.

Discover why constraints form a special category of Non-Functional Requirements and are the most challenging to test.

This bonus lecture lists other Udemy courses we offer for aspiring and practicing business analysts to improve your skills in a wide variety of areas you need to round out your toolkit.