Business analysis is a critical skill

Business analysis has been identified as the most critical skill for implementing any system, digital transformation, or supporting regulatory compliance. 

Your business analysis skills are valued by:

  • employers and future clients, as you can see from the research;

  • consultants, as you are a more valuable part of the team; and

  • your internal customers, as you speak their language.

Agile Business Analysis

You may have heard about "Agile vs. Waterfall". The waterfall methodology of development means weeks - or sometimes months - of defining requirements and documenting processes before coding even starts. 

It is called "Waterfall" because one phase does not start until the last has finished. The obvious problem is that the business has moved on before the app is delivered.

Enter Agile. Agile is an established rapid application development methodology. It is iterative and emphasizes rapid development through short sprints. These are smaller, phased deliveries of functionality, but more frequent. This keeps it more in tune with the rapidly changing requirements and priorities of the business.

Agile Business Analysis supports the Agile Development approach.

The Agile Business Analysis cycle

The Agile Business Analysis cycle has several elements (excuse the pun) which are shown in the diagram below. The boxes to the left of the dotted line are Agile Business Analysis (and are supported by Elements Catalyst), and to the right of the dotted line are the Agile Development activities.

The Agile Business Analysis elements are described below:

  • Capture Requirements: An easy, but formalized approach for capturing and managing requirements from “submitted” to “implemented”. This allows you to give more context to the requirements, add supporting information and collaborate through a comment stream.

  • Map Processes: Document end-to-end business processes with input from the requirements, ensuring everyone in the organization is on the same page and can use them as the “operations manual” to find documents, training and apps in context. This will also validate and expand on the requirements, or even generate new ones.

  • Baseline Supporting Systems: What has been configured in Salesforce and the other systems? Find out and relate it back to requirements and operational process steps so that it makes sense.

  • Write User Stories: Using the simple format, “As a ____ I want to _____ so I can ____”, write business user stories for every requirement so the dev team understand what they need to build. The acceptance criteria are now tighter as the user story is in the context of the process, and the relationships between requirements is more obvious.

  • Develop User Stories and Deliver Systems: The config/dev team take the user stories and develop their own, adding technical specs and additional information. They build, test, and deliver the apps. It may be point and click. It may be custom development, or both. It doesn’t matter. It is the same approach.

  • Governance, releases and versions: Good governance of the evolution of your processes is best practice. Every time you release changes to your systems, there are probably changes to process documentation, so make sure that you manage the updates and archive the previous versions. If you work in a regulated industry like food, pharma or financial services, you already know all of this.

Did this answer your question?