Welcome to TechRiz 

Where tech enthusiasts come for the latest tech news, Free downloads, free tutorials, articles and how to's.

“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.

What will change when you're on an agile team?
Processes, products, and relationships change on an agile team. How you plan the work, deliver the product, represent requirements, share knowledge, interact with your team and customer, manage changing requirements, and document requirements will be quite different from traditional, waterfall-style projects.

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.

Business analysts must relinquish control of the requirements, the customer relationship, and the usual requirements documentation. Why? It's because on your agile team, you deliver working, valuable software every few weeks. 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 when you learn what the need really is.

That's why I like to quote Gilda Radner's phrase "delicious ambiguity." An agile project is all about suspending control for as long as possible.

Even team roles can be ambiguous. Specifics may vary, but an agile team collaborates to deliver to a committed set of requirements. Each team member is willing, even eager, to do whatever it takes to make that happen, no matter what the official job responsibilities dictate.

It's likely that you will not be the only one to elicit, analyze, and specify requirements. 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. For example, you are likely to identify-if not also create and execute-user acceptance tests: hands-on validation. Your soft skills and understanding of requirements dependencies make you a good candidate to facilitate planning workshops to define the product roadmap and release plans.

As an agile business analyst, you're no longer shackled to large, complex requirements documentation and templates. Instead, you will influence your business partners and teams to rethink what kind of (and how much) documentation is needed. You may deliver documentation in small chunks, along with the small, useful chunks of requirements your team delivers in each iteration (often in the form of user stories). You might pitch in to develop lightweight product, user, or support documentation.

Your work is both tactical and strategic: you need to grasp the big view (the product vision, roadmap, and release plans) while maintaining a firm footing in the now (the current iteration). Thus you need the discipline and flexibility to operate in multiple modes (the "now" of the current iteration and the "later" of upcoming iterations).

Your work will be transparent. 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. The visibility of iteration planning, end-of-iteration demonstrations, and retrospectives permit no hiding. You will find greater mastery by being openly accountable to your customer, the team, and yourself.

Until next time
In the second part of this article, we'll take a close look at specific business analyst activities that differ in agile projects. We'll frame these tasks in the context of traditional requirements engineering, which involves setting the stage; developing (eliciting, analyzing, specifying and validating) requirements; and managing requirements (Gottesdiener, 2005). Meanwhile, please direct your questions to me at ellen@ebgconsulting.com.

There's never been a more exciting time to be a business analyst. Are you open to the challenge? Can you adapt your skills to your agile team's steady beat of short, value-driven cycles? Can you influence your traditional team to alter your analysis practices? Stay tuned.