The Metamorphosis of the Business Analyst

The moment projects began embracing agile principles was the moment that the role of the BA started to change.

For all of the Business Analysts that are out there reading this, I'm glad you are sitting down. What I am about to say might shock you, but hopefully you have seen these changes coming over the course of the last 6 to 12 months. The prototypical Business Analyst (BA) reached its pinnacle during the hay day of the Rational Unified Process. It was during this time that the users and the BA would lock themselves in a conference room for multiple hours a week for many months until all of the requirements had been elucidated and documented. At certain points a developer might be called in to consultant on the feasibility of certain requirements. But otherwise the developers were idle or potentially ramping up during this phase of the project.

Well I'’m here to tell you that the prototypical BA is, to quote Old Blue Eyes, "“In the autumn of the year"”. However, all hope is not lost as it is a metamorphosis and not a death that I am predicting. The driving force behind these changes is the wide-spread adoption and success of agile software development and the waning of "“Big Design Up Front" (BDUF). As most of us have experienced there are inherent problems with gathering all of the requirements up front on a project.

1. Users have a difficult time imagining how the requirements they provide are going to come to life in software. Because of this they are very skittish when it comes to asking them to approve the accuracy and completeness of the use cases.
2. Over time requirements can lose their meaning, especially if the requirement was very contextual. Context can be very hard to recreate at a latter time making it difficult to comprehend the original intent of the requirement.
3. Long delays between the giving of the requirement and the implementation of the solution can result in requirements being misunderstood and/or developers implementing the wrong solution.

To solve these problems, and others, projects began using an Agile approach to software development. In Agile working software is valued more than comprehensive documentation. The moment projects began embracing agile principles was the moment that the role of the BA started to change. No longer would a team need to rely solely on their use case documents and the memory of their BA to understand the users' requirements. To put it simply, Agile software development is focused on gathering just enough requirements to deliver a working piece of software in 2 weeks to a month. At the end of this period you do the same thing over again and you continue doing this until the project is complete or you run out of time or money. With this change users can tell the developers and the BA the "story"” of how a thin vertical slice of the application should work and the developers can immediately begin implementing the story. So what is there for the BA to do?

What Changes
The good news is that not everything changes. The BA still needs to create some amount of documentation. In the most agile groups this might mean writing the story cards, but it can also mean creating full use case documents or other requirement artifacts. Also, the BA still uses their communication and interviewing skills to draw the requirements from the users, this is still a very critical aspect of the BA's role.

Here are the new skills that will begin to become increasingly more important as Agile Software Development continues to gain momentum and wide spread acceptance.

Test Scenarios/Test Scripting
At its very basic level this skill involves writing manual test cases that can be used to verify the successful implementation of a given requirement. At the more advanced level it will involve using tools like Fit, Fitness or Selenium to write and execute automated tests.

Success Criteria
Proficiency in this skill improves ones ability to effectively write test scripts/scenarios. The ability to clearly define the success criteria for a requirement/story will enable the developer to efficiently implement a solution for the story by focusing on exactly what needs to be accomplished to achieve success.

Usability
Usability can mean many things to many people. In this context I am specifically referencing an ability to do user-centered design as a component of the requirements gathering activities. (Barrier/Challenge: How do you implement user-centered design on an Agile project?)

Customer Proxy
This is not a new skill for a BA but it is one that continues to gain importance. Teams using agile methods want to have regular customer interactions. Often it is difficult or nearly impossible to get the customer to provide a resource to use fulltime on the project. It is in these cases that a good customer proxy can improve the efficiency of the team by removing the waste created by sending questions to the customers and waiting for answers to those questions.

In summary, the Business Analyst on an agile team is just as important, if not more important, than their counterparts on non-agile teams. You will begin to see that the successful BAs in your organization are the ones that stay involved in the day-to-day development activities and that can quickly adopt (or already have) these new skills.