Life is about not knowing, having to change, taking the moment and making the best of it without knowing what’s going to happen next. Delicious ambiguity.
— Gilda Radner, actress and comedienne (1946–1989)
Agile is here, and it's coming soon to an organization near you – if it's not already there. As a business analyst, are you ready to make the transition to this value-centered development approach? How will your role change? What will you do differently? What will you actually do as part of an agile team? What agile analysis practices might you adapt if you're working on a traditional (waterfall-style) project?
In short, how can you make yourself more valuable to your agile team and organization using your business analysis skills and abilities?
It's about the work, not the role
Keep in mind my bias: it's not about the job role or title you have, it's about the work. 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.
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. A variety of people who have the skills may do the work of analysis, and it may be shared among team members. That is common in small projects or when the team members have rich business domain expertise along with close, trusting relationships with their business customers.
So if you are (or will be) doing the work of agile analysis, keep reading to find out how your life will change.
With agile, value comes from the customer
On agile projects, the customer has the responsibility – and the burden – to decide which items the delivery team will build and when, and to define each item's "doneness criteria" (when it is acceptable for release). In essence, the customer is responsible for product profitability. By understanding the product's market or business need and advocating for the voice of the (end) customer, the customer embodies the core mantra of agile teams: deliver value.
For the project to succeed, the customer must conduct a mix of strategic and tactical activities. Strategic activities include analyzing the market and business case, defining the product vision and roadmap, developing requirements, adjusting the product backlog, and determining delivery plans. 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.
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. Understanding the underlying technology also helps when making "techno business" decisions throughout product development.
With all these responsibilities, in some organizations, the business customer needs help with day-to-day tactical decision making. That's where you, as an agile business analyst, come in. On some agile teams, a BA who has deep domain knowledge (and perhaps has served in a business role) serves as the tactical customer (or, in a Scrum project, the "product owner") or splits those responsibilities with the business customer. By serving as the tactical, iteration-level customer, you free the senior business customer to be the team's strategic customer. You leverage your analysis skills to help your team deliver value, one iteration at a time. You ensure each delivery aligns to the overall strategy and goals.
Comments