#LAURA BRANDENBURG AGENDA TEMPLATE HOW TO#
#LAURA BRANDENBURG AGENDA TEMPLATE SERIES#

How To Be An Agile Business Analyst shows you how. The key is to not focus on the frameworks and prescriptions, but rather to apply your business analysis skills in an agile manner so that your team solves the right problems with the right solutions. You may look at the popular agile frameworks, notice that business analysts aren’t mentioned and wonder whether you fit. You’ll see more about how to use those techniques in the discussion of the key responsibilities below.Īs a business analyst, you have probably wondered how agile impacts your work. You and your team may also establish some agreements about what system documentation you want to create and maintain while you’re building the solution so you have reference information for future efforts. The techniques I’ve found most helpful to build and maintain that shared understanding are the discovery board and the definition of ready, along with a health dose of refining that understanding during retrospectives and general discussions among the team. You’re in effect forming an agreement – dare I say shared understanding – about what information, and what format, you and your team will use to build a shared understanding about the solution you’re going to deliver. When you work in an agile fashion, it’s helpful to focus in on the expectation setting aspect of the business analysis plan. The business analysis plan was always about setting expectations with your team regarding the output of your analysis efforts, but most people looked to the plan as a list of people to talk to and documents to produce. This change in when you do analysis means that you need to dramatically reconsider what you think of when you hear “agile business analysis plan”. I’ll explain more about what that looks like in the following posts. Your analysis work gets spread throughout the initiative to the point where you’re doing a deep dive on the backlog items that your team will most likely deliver next, while they’re working on backlog items that they plan to deliver now. Then, as your team starts to deliver small increments of the solution you do a deep dive into each subset of the solution as needed.

You do a little bit of work to establish the breadth of your initiative at the beginning, but you stay at a fairly high level. In an iterative approach, that aspect of analysis gets spread throughout the entire initiative. In most phased based approaches, you perform all of your analysis at the beginning of the project in order to create a sometimes quite substantial requirements document. Perhaps the biggest difference between business analysts in a phase based approach (often derisively referred to as “waterfall”) and an iterative approach (commonly referred to is “agile”) is when you do a majority of your work. Go to The characteristics of an agile business analyst for an introduction to this series.

#LAURA BRANDENBURG AGENDA TEMPLATE SERIES#

This is the fifth in a series of posts that take a look at the agile business analyst in terms of Laura Brandenburg’s 8 step business analysis process which serves as the foundation for Bridging the Gap’s BA Essentials Master Class.

Laura brandenburg agenda template