A fascinating topic often emerging from larger organizations is how the business analyst role should integrate with our Agile teams. In 2010, Roman Pichler crafted a blog post with a few options and I’m sure there are many other opinions out there.
Even with this knowledge and understanding of what we think could be done or what should be done with the business analyst position, I have often found there is confusion and ambiguity about how to integrate the role within the team and how to make the role appealing and meaningful.
Traditionally, business analysts would be the ones fostering a relationship with business owners and stakeholders to capture their requirements for a piece of functionality or feature needing to be built. This would be done during an analysis phase prior to any designing or coding when the analyst would be allotted time to complete their requirement gathering.
But, with the introduction of the product owner role now representing business value with requirements being captured as user stories and created just prior to working sprints, where does the business analysts fit in? How can they contribute to a cross-functional Agile team?
Building on the options Mr. Pichler introduced, here are a few of thoughts on this topic:
The first option is to become the product owner. The ability of a business analyst to pull and gather requirements and be the voice of a customer makes this a natural fit for some. They are already comfortable talking with users, customers and stakeholders and typically have natural facilitation skills.
Actually becoming a product owner may not be appealing to some as not everyone is cut out for the job. It’s a challenging role with plenty of stress and pressure. I have seen many great product owners working long hours. It does require creating a product vision and roadmap and deciding and prioritizing which features the team should build – actions business analysts don’t typically make.
If you have chosen this option:
Know what you are getting into. Understand the full range of responsibilities and competencies required to become an amazing product owner. In many regards, you will become the CEO of your product with all the expected demands and responsibilities.
Embrace the role of product owner. Becoming a product owner may be challenging but the role can also be very fulfilling. Become a whole product owner by connecting with other departments such as marketing and finance. Learn everything you can about your business and customers. Learn how to create a compelling product vision and business case and how to layout a useful product roadmap.
Build or strengthen your relationship with leadership. Your relationship with leaders will be different than it was a business analyst. Really understand the strategic vision from senior leadership and align your product vision and roadmap accordingly. By strengthening these relationships, you should be able to partner with leaders in creating the vision instead of just consuming it.
The second option would be to assist the product owner and have a role on the team. This is the most common approach I have seen implemented. Especially with complex or larger products the business analyst can free the product owner to be the “whole” product manager mentioned earlier.
Business analysts can prove valuable during product discovery or visioning by gathering market and customer research. They can also be the eyes and ears of the product owner during working sprints, answering detailed business requirement questions from the team usually directed towards the product owner.
Analysts can also author user stories for the product owner. Writing kick-ass user stories takes a special talent so having a role focused on writing them well may make sense.
Even if the product owner writes the user stories, the business analyst can elaborate the user stories as needed by the team with additional artifacts such as story boards, personas, business process flows, wireframes, and story maps.
If you have chosen this option:
Clearly define role accountability. Especially between the product owner and business analyst as any ambiguity around expectations and responsibility can cause tension later. Here is an exercise you can use to facilitate this. User stories and the product backlog should still be a reflection of the product owner and the product vision so be careful with this if you have a disengaged or weak product owner.
Become a master story writer. The anchor for any agile team is the user story. Conversation and sizing is driven by the user story and if they are not well-written the team will suffer. There are many reading and training opportunities but ultimately this will take hours of practice and feedback from the team.
Jump in whenever and wherever needed. As Roman mentions in his post, don’t be afraid to pick up tasks if you can. If you can do some testing and have the time, do it. Essentially, just be an amazing agile team member.
There may be other options you have tried. If you have implemented the role of business analysts on your agile teams, how have you been able to make it work? Are you a business analyst on an agile team? Please share your experiences!
