Why You Need a BA (Me) On Your Team

In my Do Business Analysts Need Computer Programmer Skills? blog, some comments seemed to reveal that many project managers, developers and business folks never had a Business Analyst on the team. Interesting. I think the Agile Teams who have never had a BA on a Team should be considering such folks (me! Me! ME!) for several important reasons.

Since they didn't have BAs, I have to assume the Project Manager and Lead Developers usually handled BA duties...with the top developers getting the requirements (User Stories) and helping define the tests. But only high level developers can really handle this interfacing and talking to 'real' users. The purposes, skill sets, orientation- even language are very different in both worlds. Am I saying developers shouldn't talk to users? Absolutely not- that discussion should positively take place- but there has to be a coordinator, translator and secretary to perform all these duties:

• Learn the business- its processes and needs to develop the very best product under the constraints imposed.
• Create the As-Is and To-Be documentation to begin modeling the project and processes.
  
• Create the high level functional requirements to explain the project, the reason for the project and what technologies may be used in the project.
  
• Act as the stakeholder and end users' advocate.
  
• Gather the business requirements and business rules.
• Design and help model the application with the business team and the DevTeam.
• Plan and coordinate iterations or sprints and road maps with the business team and the Project Manager.
• Translate techno-jargon to biz-speak and vice versa throughout the project.
• Test each build to avoid glaring error and/or to prepare the business for skeletal interfaces and features.
• Create, document and communicate temporary workarounds for identified issues.
  
• Create UAT scripts, run the sessions, compile the issues and comments and create a suggested priority of repair/change list.
  
• Reproduce, manage and test issue repairs (and explained to stakeholders and end users why a repair is delayed or may not be repaired.
• Create User Stories (yeah, yeah, I know, the business is supposed to do this- of course, when was the last time you saw this happen unless you were in a JAD session?), specifications (essentially all the stuff that would have been in a Use Case), wireframes, project documents and business cases.
• Handle or coordinate Change Management (them applications you guys are creating are typically going to raise hackles all over the business because you're changing things and people are change resistant.
• Perform or coordinate knowledge transfer from the DevTeam to the Help Desk and/or Admin and or DBA team(s).
• Write user training manuals, help files and doing 'train the trainer' session for large applications when required.
• Keep Scrum/Stand-up Meeting Minutes and disseminated them to the team.
• Help coordinate and communicate implementation schedules and requirements with the business and IS folks.
• Assist in creating and implementing the Risk Management Plan.
  
• Manage the Issues Tracker, the wiki (making certain business questions and comments were promptly and appropriately handled)
• Provide/create and transmit frequent status reports.

Well somebody has to do all this stuff. And those of you without BAs are probably doing a hit or miss job and know it- your time, resources and costs are cut to the bone, or you are working 10-16 hour days- which is nuts. You know this sort of assistance would reduce risk, improve team productivity and improve the communication with the business- thereby reducing the chance of rejected features/functions.

We do the things the Project Manager doesn't have time for and free up Developers to do much more productive things in terms of skill set and interest. And really good reasons why a BA is still an essential role on an Agile Team. You can also use an Information Architect (IA) for this stuff and you'd get better designed wireframes, screen themes and controls but not as much written detail (which isn't necessarily a bad thing for an Agile Project- depending in the business expectations). IAs do pretty much the same thing BAs do, but they do it visually and usually aren't as technical as a BA. But, we both get the job done for the team.

That's pretty much why I think most projects need a BA and why the BA is typically the Deputy, Associate Assistant Project Manager.

Powered by ScribeFire.