Be a champion of the Product and Customer Experience Vision
There is nothing better than a backlog refinement meeting that is getting into the nitty gritty technical details and someone says “Let’s reframe and remind ourselves what we are trying to get the user to do.”
Every user story a team works on is about a user goal, afterall a user story is about THE USER, and I mean a human user. The BA and PO should be the voice of the user on the team and continuously reset the team to the customer experience vision which is all about what action we want the user to take in order to solve for the need the user has. Most technical details and debates are quite easily worked through if everyone has the same idea on this. Focus on a shared understanding on the customer and the other details will fall into place. BAs need to be customer centric not only with the development team, but also with the Product Owner. Sometimes the PO is busy and be quote vague about the customer needs, this isn’t the time to get technical, rather the time to get more detailed about the customer. For example: “The PO says the customer needs to be able to request their password if they attempt and fail at logging in.” Getting technical is talking about the fields, databases, servers, files, and screen design prematurely. Staying customer centric is about scenarios; things like: what steps would a customer go through to request a forgotten password? How will we validate that this is the real customer? And, what would the customer see and experience if they fail such validation? Stay customer focused! Help the PO get to the next level of details about the customer.
Level set to priorities – Big picture and details
Product Owners own the backlog from the big picture and the details, they determine what the team priorities are. User Stories are often part of the backlog and they can come in varying levels of detail. Great BAs collaborating with the PO can break down the bigger user stories into smaller ones in a way that the PO can effectively prioritize the smaller stories. A great Agile BA knows how to break down and split user stories into smaller ones in a way that serves the development team and the Product Owner; this means keeping user story best practices in place to enable user focused, and feedback-able user stories. BAs work many levels of detail as user stories evolve and use these levels of detail to collaborate well with the PO and the team.
Great Agile BAs also help facilitate technical debt decisions with the PO and team. Technical debt can be tough to prioritize and it can take a good amount of conversation to create the shared understanding needed to agree on how to prioritize technical debt against new features. An Agile BA is just the person who can help facilitate the technical and business risks and opportunities to help the PO prioritize and make these trade off decisions.
Work with other teams on product synergies, dependencies and see the whole.
Especially in large organizations, teams are interconnected, or at least the products they work on are! Elevating this even further are the customer experiences and data flows! It is all connected and increasingly complex. Most BAs and POs I meet love to chat about how complex their systems are making best practices that seem so simple so difficult to follow. Analysis best practices are meant to help simplify the complexity! Not that it can actually be simplified, but analysis practices can help our brains simplify the cognitive load, helping teams find connections, solutions, and get work done faster. Great BAs and POs work horizontally across the organization to analyze cross functionally and see the whole, see the customers lens of an experience, not just the piece their team is working on. The Best BAs have a knack for seeing and connecting things outside of their own team to what the team is working on. Seeing and then working with these synergies and dependencies makes a huge difference.
Champion experiments and learn thinking with the dev team and PO
In our increasingly complex and fast moving environment, making big bets, guesses and assumptions is very risky! Many teams resort to asking the BA and business stakeholders for more detailed requirements to minimize the risk of building the wrong thing. And thought this sounds logical, it’s not usually the right approach. Complexity and change are the norm and requirements are just assumptions of what we think will create a business result or desired user behavior. Asking for more detailed requirements can go against getting results if we don’t know and things keep changing. We need to try a different approach and BAs and POs need to be comfortable leading it with the development teams and stakeholders. We need to be more experiment and hypothesis driven to learn more about what works vs. trying to get someone to guess in more detail what they think might work. Years ago we had less risk in defining more detail up front, things were less complex and changed less over time. Systems were more siloed as well. Today and in the future, the complexity and rate of change is forcing us to think about requirements differently, we need to do lean experiments, learn, and adapt to find the best solutions to meet customer needs.