Is there a role for formal Business Analysts and Systems Analysts in Agile teams?

Question

Apologies for the long ramble and fairly short question but I wanted to set the scene (as such)

Within all the blogs and articles on-line we use the term "Generalist" or "Team Member" when discussing agile teams.

However within the organisation I work for (a large corporate) we have the classic roles (PM, SA, BA, Dev, Test)

Historically we have worked in a waterfall manner or "closet" agile which basically means "Water SCRUM Fall" but we have made very good use of Axure and Balsamic for our prototyping.

However we want to improve our practices and so are looking at Microsoft's ALM tools and TFS seems a very good tool pretty much out of the box.

TFS integrates with:

• Both Excel and Project for Project Managers
• Test Manager Integration for Testers
• Storyboarding for Systems Analysts ...well almost.

It turns out for TFS needs a full version of Visual Studio to be installed to get access to the storyboarding functionality in PowerPoint, which to me indicates Microsoft feel this is a task which should be carried out by a dev.

So I guess I'm asking is there a role for formal Business Analysts and Systems Analysts in Agile teams?

If there is and others have experience out there how do they best interact with TFS?

Answer 1

Analysts are definitely needed in the scrum process. They are both the bridge between the Product Owner and The Team and one of the members of a scrum team. Their main input into the process would/could be by helping the Product Owner by determining the Product Backlog and helping the Team to define the work items, to analyze development work etc.

Their interaction with TFS is multilayered and/or non-existent depending on the type of analysis and their role within the scrum process. When analyzing the product backlog items and work items they can use the standard browser based interface to enter descriptions, acceptance criteria, or storyboards or they can do the job independently and leave this tasks to the product owner and the team.

Storyboards can be developed by using the TFS plugin integrated into Powerpoint.

We have analysts in our product cycles who are both developers, UX designers (form follows function) or product owners. We customize the standard scrum templates to add the "Analysis" activity to the task types.

Answer 2

I'm not sure I can really answer your question in its entirety, but I'm going to try and offer some input.

I believe that there is very much a role for business analysts in an Agile team. "System Analyst" is a relatively generic title (since I'm not familiar with your company structure), but I can imagine that the position is similar to a software architect. At any rate, the business analyst position has played a huge role in my previous experiences with companies. However, its important that you understand the true role of your business analyst. In my examples, the business analyst played the role of intermediary, tester, and functional expert. This person would serve as the primary channel of communication between the business resources and the technical resources. He or she would have an extensive operating knowledge of the area of business he/she was assigned to, and would participate in all stages of testing during a project's life-cycle.

But I digress. The systems analyst (architect) serves the role of technical planning and implementation, as well as thorough testing and technical subject matter expert. The business analyst serves in the above-mentioned role, and also serves as the primary planner for the Agile life-cycle (assigning iterations, story points, etc.) So yes, I believe both positions have a very active role in an Agile team.

As far as TFS (which I'm going to assume stands for Team Foundation Server), it is a very, very robust product. In my personal opinion, TFS has more value to a business analyst. This product (among many other things) allows the analyst to engage in a thorough Agile project plan through iterations, backlogs, and stories. TFS' tool-set allows for easy management of these aspects of the project. It also allows for project forecasting, team member management, and easy-to-use UI and visual tools for story-boarding and task management.

Some of the features that an architect would enjoy including TFS' continuous build engine, configuration management, and unit testing/refactoring tools. It also has easy integration with the business analyst's planning portion by offering transparency into tasks.

I would recommend some more research online to get the most out of everything TFS has to offer. The true downside to using Microsoft products is the price. But if money is not an issue, I would definitely give TFS a look. Try a trial run of it, and do a cost-analysis.

I hope this helped at least a little bit.

Answer 3

It should be noted, from experience, there are some pieces that don't smoothly integrate with MS Project and TFS. For example, in TFS, you can only have one resource allocated to a task and you will have to update your project schedule to conform if you want to keep them in sync. If you're breaking down tasks at such a level that they can be assigned to one person already, this shouldn't be too much of an issue though. Also, if you need to assign tasks, such as UAT tasks, to a customer not in AD, you cannot.