From the course: Agile Requirements Foundations

Agile principles 1–4 from a business analyst perspective

From the course: Agile Requirements Foundations

Agile principles 1–4 from a business analyst perspective

“

- The principles of the Agile Manifesto bring clarity to what being agile truly means. It's more than doing agile, it's about being agile in our behaviors and mindset. The principles don't talk about the BA role or requirements for it specifically but they are still very meaningful for the business analyst role. Here's my take on what each of these mean to business analysts and requirements. Number one, our highest priority is to satisfy the customer through early and continuous delivery of valuable software. BAs facilitate the dialog that helps the product owner prioritize what the team builds. BAs understand what will delight users and satisfy customers. BAs support continuous delivery by facilitating the breaking down of functionality into small pieces of value. No one else provides this perspective. Business leaders see large chunks of functionality and the technical team focuses on technical components and technical layers. As a BA, you advocate for the users and customers by identifying small increments of value that users can see and experience. BAs define these increments so they can be prioritized, estimated, and worked on efficiently. Next, number two. Welcome changing requirements even late in development. Agile processes harness change for the customer's competitive advantage. As BAs, we facilitate the team in discovering emerging thoughts and ideas that will make the product more valuable. External market changes and feedback from customers continuously influence the product and BAs help incorporate this feedback into the product backlog and priorities. Changing requirements are good. They mean the product is getting better than previously imagined. The third principle, deliver working software frequently, from a couple of weeks to a couple of months with a preference to a shorter timescale. BAs are key to helping customers and business leaders realize the intended benefits of a product sooner. BAs slice work into small increments of value and help the team analyze business value, technical dependencies, and technical debt. BAs are a critical player in facilitating the needed dialog on the team to not only ensure the software works but then it's also valuable. It can be one thing to build great software and yet a different focus for the team to make it valuable from a customer perspective. Many times, discovering the value to customers means experimenting and learning from seeing users use and react to working software. And the fourth principle. Business people and developers must work together daily throughout the project. BAs are engaged and available to the team on a daily basis. They facilitate continuous conversations throughout the day using high impact collaboration and communication that results in rapid learning and fast decision making. When this is done well, requirements and documentation are kept lightweight. The focus is on dialog rather than cranking up documents. These are the first four principles. I hope you are seeing how important these are to your role as BAs. Next, we'll look at principles five through eight.

Contents