The transition to agile methodologies often leaves the business analysts (BA), wondering where they fit exactly. What disappears our role? At all. In fact, it becomes more critical than ever, but requires a fundamental transformation in how we operate. Since we are not the guardians of requirement documents monolithic; now we are the facilitators of the continuous value.
As a Business Analyst, Global Product Manager-Agile, I have seen first-hand how success in this new paradigm is not about doing less analysis, but doing different. Here I share the keys to optimize our role in the ecosystem agile.
1. The ‘Big Upfront Requirements’ to the ‘Just Enough, Just-in-Time’
The most common error is to try to define everything before the start of the development. This is the antithesis of agility. We must adopt the mindset of ‘enough and time’.
Instead of writing specifications of 100 pages that will be obsolete in a few weeks, focus on refining the backlog for the next sprint. The goal is to have user stories that meet the criteria INVEST (Independent, Negotiable, Valuable, Estimable, Small, and Testeable) just when the development team is ready to address them. This reduces waste and allows us to pivot quickly if the needs of the business change.
2. Become the ‘Proxy’ of the Product Owner, not in his Secretary
In many computers, the BA ends up just taking notes for the Product Owner (PO). This is a waste of talent. Your role is to be a strategic partner of the PO.
While the PO is focused on the product vision at a high level and in the prioritization of the roadmap, you should focus on the feasibility and detail. Help the PO to break down epic complex stories manageable, analyzes the dependencies of technical and business, and make sure that the acceptance criteria are clear and concise. You are the bridge that translates the strategic vision in increments of working executables.
3. It fosters Communication face-to-Face about the Documentation
The Agile Manifesto values ‘individuals and interactions over processes and tools’. A conversation for 15 minutes in front of a blackboard with a developer and a tester is infinitely more valuable than a requirements document of 10 pages sent by e-mail.
Using visual models, flow diagrams and low-fi prototypes to facilitate these conversations. The documentation does not go away, but it becomes a result of the collaboration, not a prerequisite for it. Documenting key decisions and domain models, not each interaction of the user interface.
4. Integrates the Feedback Early in your Analysis
The analysis does not end when a story comes in the sprint. You must be present during the development, answering questions, and accepting that what is being built matches the intent of the story. Actively participates in the Sprint Reviews to see how users interact with the increase and use that feedback to refine the analysis of the future stories. The analysis is now a continuous cycle of learning and adaptation.
