We always hear that,
- BAs should present/protect the Engineer team while talking to the business
- BAs should tell engineers what to do and how to do it
- BAs should write the Acceptance Criteria to cover all scenarios
- BAs should always have solutions before talking to the Engineers
- BAs should be innovative to provide ideas
Well, BAs are carrying too much pressure. Don’t forget BA is just one role in a team. The team should be responsible for all these responsibilities.
However, BAs do need to know how to collaborate with engineers to accomplish goals as a team.
How? Let’s recognize engineers as our customers. Then what is Engineers’ “Job To Be Done (JBTD)”? You can refer to my last post to know better about JBTD. How can the JTBD validate the requirements?. The Engineers need to get their tasks done “properly”. Here “properly” means making sure their delivery can meet the business need and bring business values.
What do the Engineers need to finish their JTBD? They need to know what is the right thing to build, and then they can think about how to do it accordingly.
When we are talking about “what is the right thing to build?” is this means that only BA should provide the solutions. Probably not. BAs are just humans, and one human being might be able to think of all the scenarios. We should know our limitations and get help from our Engineer team. However, don’t be afraid to propose solutions. It is always a good start point to discuss.
When we talk with the Engineers about a requirement (often presented as a user story, but it can be other techniques), we should provide all the context needed at least including,
- Who we build this feature for
- Why do we need to develop this feature
- Which part of the feature is this user story about
- What is the scope of this user story (any acceptance criteria, any test cases)
It is like when we are building a car. We split all the tasks for building a car into “user stories”. One of the user stories is to make the wheels. Without tell the engineer that what we are creating is a car as the big picture. The engineer might finally deliver a motorcycle wheel.
The Value and context are like a big picture of the system we are building and ensuring that the engineer knows how vital this user story is as in this system. He will feel proud of doing that card and will take ownership. With this ownership, the engineer might think of other solutions to meet the exact business value, as he knows all the details that BA might not know. In this case, don’t feel that the engineer challenges you. Instead, try to understand the solution they proposed. It is ok that their solution is better than ours. Our goal is to meet the business value, not to prove that we are right and the best. So accept the best solution whenever we can.
Now BAs can feel a bit of relief, right? All we need to do is to use our knowledge and techniques to work with the whole team to accomplish our goals as a team.
