Business Analyst: The Product Owner’s Trusted Advisor

 

Any person in your company or on your team can sit down and chat with the Product Owner.  But are they leveraged consistently to strategize about the customer and value the product provides?  A trusted advisor is an individual that is given a seat at the table. Instead of being just another team member, the Product Owner sees you, the Business Analyst, as a strategic advisor and an enabler to reach their goals.  All agile delivery team members play a role in the delivery of value, but a trusted advisor tends to be involved in discussing what the customer and stakeholders require, what value the product is bringing and risks associated with the delivery.  Trusted advisors get to hear and offer new ideas and help the product owner make informed and useful decisions.

There are two value lenses which the business analyst focuses on, product value including techniques to identify and elicit information and process value including options on how to continuously improve.

  1. From the product perspective, the BA plays a critical role in the gathering and analysis of feedback which guides decisions on the product backlog. They help to identify and define what is value.   In addition, they help to uncover what the problem is we are trying to address and solve and why is it important.
  2. From the process perspective, the BA gives consideration on what impacts the creation of value and how the team might do things differently to create additional value through continuous improvement.

As the trusted advisor, the Business Analyst will share the information and details collected from the product and process perspectives with the Product Owner so they can evolve and update the backlog.

Agile Requirements and Analysis: Mindset and Simplicity are Key!

An agile mindset drives agile business analysis practitioners’ thinking and behaviour.  Having an agile mindset emphasizes the agile values and principles while focusing on maximizing value.  One goal of applying an agile mindset is to maximize the outcome, value delivered, with minimum output.  In Disciplined Agile, the principle of Optimizing Flow speaks to eliminating waste, making workflow and improving continuously.  Agile requirements and analysis happen throughout the entire life-cycle of product development, not just at the beginning.  As such, ensuring flow and continuously improving is a critical piece of requirements and analysis to ensure the team is maximizing value delivery.  Agile analysis requires the application of multiple techniques that are fit for the problem at hand and are adapted as needed.  The delivery team, subject matter experts and stakeholders should be actively involved in requirements discussions.

Qualities of analysis in agile environments include:

  • Being iterative and incremental, generally detailing out requirements approximately 1.5 to 2 sprints ahead of the delivery team.
  • High Collaboration with preference to conversations over documents.  Note: ensure the documentation captured satisfies and is appropriate for your organizations’ context.  For example, a new start-up with limited regulations may have lighter weight documentation needs than a regulated, government body.
  • Transparency through collaboration and lightweight artifacts.  The use of sketches on the whiteboard or capturing decision points is preferred over detailed models and detailed specification documents.
  • Artifacts evolve as the team delivers and gathers feedback.
  • Requirements are executable with preference to acceptance tests over detailed specification documents.

From the product perspective, as a trusted advisor to the Product Owner, the BA needs to ensure that the problem at hand is surfaced by helping the product owner and subject matter experts identify ‘the what’ in their user stories.  We do this to ensure we are solving the root problem and not just putting band-aids on symptoms.  By surfacing the problem and why it is important to the product, the user, the customer or the organizational strategies – it helps the delivery team stay focused, ask better questions, design appropriate solutions and have empathy for the user.

The BA has options when it comes to adding value through the process perspective.  Disciplined Agile spells out multiple lean and agile life-cycles for a team to choose from.  Context counts for teams when choosing the best process and practices for their team’s unique situation, the product they deliver and how they deliver it.  With a lens on the process, the BA can give consideration to what is impacting the creation of value.  The Business Analysis can facilitate team process improvements by asking questions like:

  • What can help the team increase their engagement?
  • Are defects or impediments being reduced?
  • What is the expected benefit of a proposed improvement, and which one might be most important to the team?
  • Is our team adding value to the product/customer every sprint?
  • What is the next action we will try to improve our process?

You, the Business Analyst, are the Product Owner trusted advisor.  Continue that strategic relationship by having a close lens on both the Product and Process value the team is delivering.  Want to up your game and learn new techniques for continuously improving?  Check out our Courses page for upcoming workshops or reach out to one of our Tactec Disciplined Agile experts for coaching support.

Ready to level up your career?

Recent Posts

CIO

Born 1965, San Antonio, Texas and lives in Dallas, Tx.
Mr. James, Ronald, Maverick holds a Bachelor of Science in Psychology at The University of Texas, San Antonio.

Mr. Maverick or JR as many call him is a “slick” but warm and friendly character in our upcoming book on the DevOps Mindset. Mr. Maverick cares about his IT team very much and could charm the socks off a Texas Longhorn. JR is liked by many in his organization; however, he is not as well trusted by the Overlords as he used to be. Mr. Maverick has a group of loyal staff, including Mr. Barker a bit of an opposite to JR. Of course, Mr. Barker would never call him JR; he would only call him Mr. Maverick because well, Mr. Maverick is his boss. Mr. Maverick has held many IT positions in the past, including starting as a Sales Professional for HP and IBM mini and mainframe computers. Over the years he has risen through the ranks to hold this senior position by delivering using high-paid consultants and Big name firms. He also received his promotion from outsourcing to a foreign country where he was able to reduce his IT spend significantly. Recently he has discovered (actually this was made painfully aware to him by the Overlords) that both the Offshore roadmap and use of external consultants was not giving him the value and velocity for his IT department, and he was probably paying more than he bargained for

So, after hearing a talk at a DevOps event by the Agents of Chaos, JR decided to enlist them to help with their digital transformation roadmap and help improve the value, focus and velocity of his department. However, MR. Maverick has a few ideas about agile and DevOps, something he has heard about for a while and read in various CIO magazines; he thinks of these as Marketing terms and something that can be bought. While Mr. Maverick has held on for many years to traditional IT ways of working he has come to the end of his tenure if he doesn’t do something fast and get DevOps working quickly as he has promised to the Overlords providing him with a little more rope to get the transformation completed more quickly as they view his IT department ageing, procrastinators who are not able to keep up with business demands. JR says in his mind, “I will get it done, they don’t call me Maverick for nothing!“