How will your role change? The customer also conducts tactical activities such as specifying the items to be delivered in each iteration, determining when each item is complete, analyzing dependencies between items, and helping the team analyze requirements stories. So when I use the term "agile business analyst," I mean anyone who is doing the work of requirements (business) analysis on an agile team. In short, you will be part of a team of highly collaborative colleagues with a furious focus on delivering value, negotiating value delivery in short cycles, and helping your business partners understand what they really need-not only up front but also as the product unfolds in small, usable chunks. To fulfill both strategic and tactical activities on an agile project, the business customer needs product development experience, along with deep domain and product knowledge. You will find greater mastery by being openly accountable to your customer, the team, and yourself. You leverage your analysis skills to help your team deliver value, one iteration at a time. The team is focused on delivering "shippable" software in short cycles (iterations), so your tasks may cross over to other activities that call on your skills, capacity, and interest. Modeling business processes and system requirements, architecture and data In addition, the business analyst may be expected to support devel… For the project to succeed, the customer must conduct a mix of strategic and tactical activities. Maintaining the user stories in the product backlog 3. Instead, you will influence your business partners and teams to rethink what kind of (and how much) documentation is needed. And you (and your team and customer) don't know exactly what the end product will be-not until you start to build it, deliver it, and get feedback on it. That's where you, as an agile business analyst, come in. Some agile teams may not have a team member who is the designated business analyst, or they may have a business analyst whose only role is business analysis and requirements-related work. Delicious ambiguity." In essence, the customer is responsible for product profitability. Why? You will get better at estimating and working with your cross-functional teammates to reliably predict how much software your team can deliver in each iteration. As an agile business analyst, you're no longer shackled to large, complex requirements documentation and templates. Author of two acclaimed books Requirements by Collaboration and The Software Requirements Memory Jogger, Ellen works with global clients and speaks at industry conferences. Getting Requirements Right with KickOffs and Desk Checks, « The Bad Ass BA Observes the “Hunt for the Right BA”, Part 2, Thinking Outside of the BOKs Professional Inclusivity Beats Silos, The TRIFECTA – Bringing Together People, Process & Technology. For example, you are likely to identify-if not also create and execute-user acceptance tests: hands-on validation. A variety of people who have the skills may do the work of analysis, and it may be shared among team members. As an agile coach, trainer, and contributor to the agile IIBA BABOKTM agile extension, Ellen is passionate about sharing the value of agile practices for analysis, and the discipline of analysis for agile value delivery. A variety of people who have the skills may do the work of analysis, and it may be shared among team members. What will you actually do as part of an agile team? Your work will be transparent. Don't forget to leave your comments below. The visibility of iteration planning, end-of-iteration demonstrations, and retrospectives permit no hiding. An agile project is all about suspending control for as long as possible. Business analysts must relinquish control of the requirements, the customer relationship, and the usual requirements documentation. Stay tuned. In the second part of this article, we'll take a close look at specific business analyst activities that differ in agile projects.