Image may be NSFW.
Clik here to view.
Have you ever been handed a set of designs and expected to infer the functionality of the elements in them? Do you sometimes begin creating a template or component and realize you don’t know what the author should be able to do? Do you find yourself reworking components because you had to do some initial guesswork, but your assumptions did not align with the client’s expectations? If so, your project needs a Business Analyst (B.A.).
What Does a B.A. Do, Anyway?
Depending on the size and nature of your organization, you may have a fully staffed team of experienced B.A.s, or you may have never worked with one before or even know what we do. In short, a B.A. acts as liaison between the business or client, and the development team. We bridge the gap between these teams to understand the client’s needs, help devise and propose solutions, and then translate those into detailed development requirements and acceptance criteria.
Typically, our work on an Adobe Experience Manager implementation begins when designs are handed off to the dev team, but it can also start earlier with initial discovery. The B.A. can participate in discovery on the current state and future needs of the client’s assets, integrations, taxonomy, architecture, user groups and permissions, content loading or migration plans, and SEO. This knowledge helps define the full scope of the project and allows the technical team to consider the “big picture” when designing solutions.
Requirements gathering and documentation are at the heart of what the B.A. does. When designs for an implementation are delivered, we work with a Technical Architect (typically the lead developer on an AEM project) to break them down into templates and individual components, and start to build out the documentation that will eventually serve as requirements.
How are Requirements Documents Created and Why Do You Need Them?
Next, we do the work of actually gathering the requirements from the business. This is where the B.A. is invaluable to your project. The Business Analyst will interview key stakeholders, subject matter experts, and content authors to fully understand their needs and goals, and then use that knowledge to write detailed functional and authoring requirements. In this phase, the B.A. acts as an advocate for the business, particularly for the authors, by recommending best practice solutions that will ultimately deliver a great product and painless authoring experience. But we also aim to help you, the developer, by clearly defining what’s expected, and taking the guesswork out of the dev work.
Once we’ve documented requirements and vetted them internally, we present them to the client for approval in backlog grooming and sprint planning sessions. There are often many conversations and several rounds of revisions before both teams agree on requirements, but getting that official sign-off is crucial; it ensures that everyone is in agreement on exactly what will be built. This guards against the unnecessary and costly churn that happens when tickets have to go back to development multiple times in a sprint because the requirements weren’t clearly defined. It also protects the project team or the agency if a client decides they need something different than what was initially agreed upon. And it streamlines Quality Assurance (QA) and User Acceptance Testing (UAT) efforts by eliminating ambiguity around whether a component is complete and production-ready.
To give you an idea of what our requirements include, I created an example as if I were writing requirements to build a simple footer component for the Axis41 site. Below is a breakdown of each section of the document. Notes on how certain fields are used are highlighted in yellow. Click any image to view a larger version.
Example Requirements Document
Basic Information and Acceptance Criteria
The top section contains high-level information about the component including a list of key team members, a link to the epic ticket in JIRA which ties together all other related tickets, the requirements document’s status (draft, approved, complete, etc.). This section also contains the acceptance criteria that will be used for QA and UAT.
Image may be NSFW.
Clik here to view.
Business Requirements
Business requirements explain the need for the component, or the problem the component will solve, and how it will be used by the business. In some cases, business requirements are more detailed than in this example, but they’re pretty straightforward for something like a footer component.
Image may be NSFW.
Clik here to view.
Design
Next, we include annotated screenshots of the component design at each responsive breakpoint. The letter and number annotations correspond to fields in the Functional Requirements table in the following section.
Image may be NSFW.
Clik here to view.
Functional Requirements
Functional requirements are outlined in a table that corresponds to the design annotations (above). Functional requirements break down the business requirements. Each element is defined, including how it should behave, how a user can interact with it, and any authoring requirements. It’s helpful to think of business requirements as the “why” and the functional requirements as the “what.”
Image may be NSFW.
Clik here to view.
Additional Links and Notes
We aim to make our documentation as comprehensive as useful as possible. At the bottom of the document, we use a macro to pull in every JIRA ticket that has been associated with the component or template so a user can see the status of all tasks or bugs at a glance, and click on ticket number to go to JIRA for more detail. We also capture notes, questions and answers, or requests for potential future enhancements in this section.
Image may be NSFW.
Clik here to view.
In my fictional example, I would have worked with the business stakeholders to determine how each element should behave, how much flexibility authors should have, and which elements should not be editable. Without those details, developers have to make assumptions about what the client needs, which can lead to expensive and time-consuming re-work, and frustration all around.
The B.A.’s Role in Moving the Project Forward
As part of the backlog grooming sessions where we discuss these requirements, we often work with the business to prioritize and define a Minimum Viable Product, or MVP, release. In some cases, an MVP may be the client’s first foray into Adobe Experience Manager, and a limited first release can help them learn the system which will better inform future iterations. Once they’ve had a chance to really work with AEM and update content on their site, they’ll have a much better understanding of their needs going forward.
Sprint planning sessions are also important because that’s where we estimate the level of effort involved in each development task. The B.A. polls the dev team to come up with estimations and then helps the client prioritize the next wave of work based on the project team’s proven velocity. This protects the team from being overcommitted and aligns expectations on all sides as to what will be achieved in the next sprint.
The Value of an Experienced B.A.
Among Business Analysts on my team, there is a range of expertise in AEM; we work on a variety of platforms so we have all gained some level of familiarity with multiple applications. While the “nuts and bolts” of various platforms are specific to the particular application, the fundamental principles of business analysis remain the same from one project to another. One does not need to be an expert in Adobe Experience Manager in order to bring value to a project, but a B.A. with a wealth of Adobe Experience Manager experience will be able to take a more consultative approach rather than just a documentary one.
Every Business Analyst at this agency would tell you that they have never worked on two implementations that were the same. Of course there are always commonalities between projects, and we draw on past experiences to suggest practices and processes that have worked well for other clients, but each implementation — and client — is unique enough that we must also rely on our critical thinking and problem -solving skills in order to be successful. The true value of a B.A. as part of the project leadership team is in our ability to gain a deep understanding of the client’s objectives and needs, apply our platform knowledge to recommend optimal solutions, think strategically, reinforce best practices, and drive the project team toward sprint goals to ultimately deliver an exceptional product.