By Steve P. Blais
November 9, 2022
You get the word: “We are going AGILE!” Software development is going to adopt Scrum as its operating approach to developing software. And that means no more business analysts. Just as there is no crying in baseball, there are no business analysts in Scrum. Now what do you do? Put your resume out? Ask for a transfer to another area within the organization that still uses business analysts? Go back to school to brush up on your Astro physics and change careers? You won’t be able to segue into project management since there are no project managers in Scrum either.
You might consider one of the three roles available in Scrum: Scrum Master, Product Owner, or Developer.
One of the options many business analysts gravitate to when Scrum is introduced in their organization is the product owner.
Business Analyst and Product Owner Similarities
Many of the skills honed and developed by the business analyst are applicable to being a good product owner: gathering information, analyzing the information, documenting the information, discovering and defining business problems, coming up with creative solutions, and so forth. However, the success as a product owner will depend on how well you have applied these business analyst skills and, of course, a few other aspects.
Business analysts who have also been project managers, or who do double duty as both project managers and business analysts, will have the easiest transition to product owner, especially if you have had some technical background. However, even if you are a new business analyst with limited experience, you can succeed as a product owner if you focus on certain aspects of your business analyst role.
Start by doing the primary thing you do as a business analyst ― gather information. Sharpen your interviewing and elicitation skills. As a PO you will still be coordinating with the businesspeople and stakeholders, asking questions and discovering or helping them to discover what they need, what problems they have, and what can be done to make their jobs easier in pursuit of achieving their objectives.
You should also work on your analysis skills as you will be analyzing the information to produce problem statements that you need to solve. The difference is that instead of producing a problem statement, solution, and detailed requirements, you will produce a product backlog. The product backlog is basically a big TODO list which identities everything that needs to get done to solve the problem.
The Product Backlog
One of the significant differences in the approach of the business analyst and the product owner is the documentation of the requirements for the solution. There are no business requirement documents in Scrum. The Business Requirement Document (BRD) has been replaced by the Product Backlog. The Product Backlog is essentially a prioritized list of everything that is to be done by the solution team to develop the solution to the business problem. The BRD is an unprioritized record of what needs to be done to solve the business problem, similarly, but clearly with some important differences.
The same general rules that productivity and time management experts impose on TODO lists apply to product backlogs:
- The backlog is prioritized with the most important task or item at this point in time based on the information available to the product owner listed at the top. The least important item is on the bottom.
- Those performing the tasks or accomplishing the items (you, if it is your TODO list) extract only the number of items from the product backlog that they can reasonably expect to get done within the time frame allocated.
- If an item is too complicated or will take too long to do within the time frame allocated, it is broken down into smaller tasks which are then added to the backlog in order of priority.
- For each item on the backlog there is a condition to be met which proves that the item has truly been done and a test that can be performed to verify it, at which time the item is removed from the backlog.
- New items are added to the backlog by the product owner as they are identified and placed in the backlog according to the product owner’s estimate of their priority.
- The backlog generally is never completed.
In addition to the product backlog replacing the BRD, the product owner has authority that the business analyst relinquished to the project manager. Business analysts generally rely on their communication skills: negotiation, mediation, influence, and networking to get things done rather than authority. This is a difficult hurdle for many business analysts who chose the BA role primarily because they didn’t want the authority.
Unlearning
And, you may have to “unlearn” some things. For example, the mindset that all details and requirements need to be set up front before you start. Keep delaying making decisions until the last moment and keep telling yourself that you can resolve the details at the appropriate time during the sprint planning session. This basically means improving your patience skills.
Another area business analysts have some trouble with is letting go, or as they say in the world of project management: delegating. For most of my career, and of the careers of the vast majority of experienced business analysts, we have been lone wolves. There are few teams of business analysts working on the same project, and even then, for efficiency’s sake, the BA team members tend to gather information singly and then combine the information they gathered. BAs have a tendency to want to jump in and gather information themselves and solve the entire problem themselves. The PO, who has way more work to do than allowed for in a work week, has to learn to delegate to others, including other business analysts, and let them gather the information, providing them with the general questions that need to be answered by the business stakeholders or others who have requests of the overall product to define or revise the backlog.
The Basic Translatable Skills
In general, there are three basic business analyst skills you need to focus on to be a successful product owner…someone who drives the development of a product that is successful for the organization.
- Determine what is really needed. In this case, the business analyst acting as product owner has to make judgments about the information received. The business stakeholders will ask for many features and functions all of which might be excellent in terms of marketing or sales, but only some are necessary for a successful product. The product owner needs to be aware of the concept of MVP (Minimum Viable Product), which is the most basic version of the product that meets the minimum necessary requirements for successful usage. The remaining hopes, dreams, and other expressions of requirements provided by the business community are icing on the cake. They might make the product easier to sell, but they are not necessary for the product to work. The product owner needs to focus on what is necessary and separate those functions’, features, and requirements from everything else no matter how attractive “everything else” seems to be. Business analysts generally have the skill and are able to help the users and business stakeholders (who typically don’t know exactly what they want, or what is capable of being produced), to focus on solutions to their problems. Business analysts who are used to simply giving the users and business stakeholders exactly what they asked for, as opposed to what is necessary to solve their problem, will find that they will be less than successful as a product owner.
- Know what is necessary to create a good product. The business analyst, by virtue of his or her position, will know more about the technical aspects of developing software or creating a technology-based product than the business stakeholders. Many business analysts, like myself, have backgrounds in technology, engineering and software development, and so have a good feeling for what it takes to develop a new software application. It is generally easier to learn the business than it is to learn the intricacies of software development. And lacking that knowledge of technology means that the business-oriented product owner might, as has happened, request the display of data from the new database to be completed before a lower priority item of building the database. If for no other reason than to establish respect and good working relations with the development team, the business analyst from the business side should spend time learning the technology; at least enough to understand what the development team is talking about. While you as product owner have to keep the focus on the business, remember two things: 1) in scrum, the product owner is a member of the team, and 2) software developers do not like to explain simple computer concepts when they could be coding.
- Communicate. Communicate. The central activity of business analysts is to communicate. Communicate with the users, the business stakeholders, the development team, the project manager, upper-level management and so forth. In many teams I’ve observed, the project manager passes the responsibility of keeping everyone informed off to the business analyst, who theoretically has better training and ability to communicate. Is there more requirement for communication as a product owner than as a business analyst? Probably so. But even if not, the type of communication you are going to be doing is going to be different. While you will still be answering questions about the product posed by the solution team, you will also be directing the team in what they do (the prioritized backlog). While your will still be asking questions of the business community to determine what needs to be done, you will also be making decisions and judgments on the information they give you, and then explaining your judgments and decisions to them in a way that they will accept. As a business analyst you are not directly responsible for the success of the project, as that is the domain of the project manager. As a product owner, you are the responsible party for the project and, more importantly, the ultimate product.
So what to do…
If you are picking up a PO role in an ongoing project:
- Spend time learning the business and the product. As a PO, you will always have to be the expert in the product being developed since you will be answering all questions from the solution team and making all decisions about the product (what it is, not how it is developed).
- If you are not at least moderately knowledgeable in technology (at least the technology being used to implement the backlog items), do some studying or ask questions so that you will understand what the developers tell you about the Backlog items and their progress.
- Pick up or practice some project management techniques such as interacting and negotiating with the developers, delegating, directing the product work to be done, prioritizing, creating product roadmaps (precedence network charts) and so forth.
- Finally, and above all, you will need to focus on your communication skills in all aspects. Every one of the communication skills (negotiation, mediation, conflict resolution, influence, verbal presentation, written presentation and so forth) will be called into use. While the items on the product backlog can be ambiguous and unclear, you need to provide explanations to the solution team that are clear, precise, and unambiguous so they can create their estimates, set scheduling and deliver the right product. You must be able to mollify competing business stakeholder groups who want their requests higher on the backlog. (Remember that unlike the BRD, the product backlog is visible to all.) You have to be able to provide a rational explanation to upper-level management as to why the delivery of the final product might take longer.
Being a product owner is a challenge. It may be more of a challenge to you than your worst business analyst experience. There are a lot of new tasks and activities to undertake and, most importantly, the greater, much greater, responsibility associated with bringing a product or business solution to fruition. So, if you are having second thoughts about the role of product owner, perhaps Scrum Master might be the way to go. And, of course, the role of business analyst still exists in and around Agile and Scrum.
Steve Blais, PMP, PMI-PBA, is an author, consultant, teacher, and coach who has over 55 years’ experience in Information Technologies working as a programmer, tester, project manager, business analyst, system analyst, general manager, and corporate executive. He has helped start up five different technical companies over the years.
Steve is the author of Business Analysis: Best Practices for Success (John Wiley, 2011) and co-author of Business Analysis for Practitioners: a Practice Guide (PMI, 2014) and a contributor to the Business Analyst Body of Knowledge, V3 (IIBA, 2015). His new book, The Digital Transformation of Business Analysis, published by IIBA Press, 2023.
