The Scrum guide says the following about the Product Owner role:
The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
Some responsibilities between a Product Owner and Business Analyst overlap. However, we need to pay close attention to more details in a transition. Still, the shift makes sense and can happen smoothly.
Focus on Communication over Documentation
When I was a Business Analyst, I used to work within the traditional software development approach. The process was time-consuming and extensive:
- Business Analyst writes the requirement document;
- Sponsor approves the requirement;
- Development Team follows the instructions;
- The QA Analyst tests the development;
- The Release Manager releases the software.
It was complicated for me to move from a traditional approach to the Scrum Framework. In the beginning, I was skeptical if it would work because the process was so lightweight. However, the vital part was to understand that communication is a key point for a successful team.
As technology, market, and environmental complexities and their interactions have rapidly increased, Scrum’s utility in dealing with complexity is proven daily.
Scrum proved especially effective in iterative and incremental knowledge transfer. Scrum is now widely used for products, services, and the management of the parent organization.
The essence of Scrum is a small team of people. The individual team is highly flexible and adaptive. These strengths continue operating in single, several, many, and networks of teams that develop, release, operate and sustain the work and work products of thousands of people. They collaborate and interoperate through sophisticated development architectures and target release environments.
As a Business Analyst, I would spend a maximum of 20% of my time with the development team because the focus was on following the process. With Scrum as a PO, I spend a minimum of 30% of my time with the development team. Surprisingly, the team’s productivity skyrocketed because collaboration fosters engagement and motivation.
Individuals and interactions over processes and tools
Be Part of the Team
In my scenario as a Business Analyst, I was part of a business team. In this case, I was separated from the development team, which created silos. Business Analysts focused on the strategy, requirements, and so on, while the development team focused on building software. We didn’t have much interaction; our main communication was to discuss the documents’ details and ensure the same understanding.
As a Product Owner, we are part of the team. It is vital to understand we are on the same level as the other members. Some Product Owners believe this role is on the top of the team; this is a vast misunderstanding. As a team, we are all responsible for the outcome. Therefore, the Business Analyst in the transition to the Product Owner needs to learn how to be part of the Scrum Team.
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity. The Scrum Team has proven itself to be increasingly effective for all the earlier stated uses, and any complex work.
Avoid thinking everything upfront
When I was a Business Analyst, I was used to writing extensive and very in-depth documentation, so that I was sure all the edge cases and business rules were covered. Also, I needed to get formal approval from the sponsor. Then the development team would be able to work on it.
The Development Team was literally following the instructions; there was no room for discussion on it. The document would have all details, including wire-frames, business rules, and so on. Sometimes the documents would even have technical details like the entity model relationship.
Skipping extensive documentation was something I needed to change drastically; I couldn’t understand how a team could work without that amount of information. I also didn’t understand how the business would accept something without formal approval. For me, it was crucial to understanding the Agile Manifesto; it was a huge change of mindset, which took the whole team to a higher level.
Working software over comprehensive documentation
In Scrum, there’s no requirement document; instead, there is the Product Backlog, which has the Product Backlog Items. They represent the work which the Development Team will have to do. A great Product Backlog Item is no more than an invitation to start a conversation.
A great Product Backlog Item starts a conversation. The goal of this conversation is to establish a common understanding. It is impossible to perfectly describe what you want to build. The best you can do is try to get everyone on the same page and reach consensus in their mind.
Also, it is important to understand what the Scrum Guide says about the relation between the Product Owner and the Product Backlog.
The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:
Clearly expressing Product Backlog items;
Ordering the items in the Product Backlog to best achieve goals and missions;
Optimizing the value of the work the Development Team performs;
Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
Ensuring the Development Team understands items in the Product Backlog to the level needed.
The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.
Business Analysts generally don’t make the final decision over a requirement, which was my case. I could neither approve a requirement nor define which was a priority; only the sponsor or someone else defined by him or her could make such decisions.
In the role of a Product Owner, the scenario is different, since Product Owners make many decisions daily. The Product Owner is responsible for the product direction, thus being accountable for the Product Backlog as well as defining what has to be done and what will not be done. The Product Owner also decides when it makes sense to work on each Product Backlog Item.
In this scenario, during a transition, the previous Business Analyst will need to exercise how to make decisions and be accountable for those.
For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one can force the Development Team to work from a different set of requirements.
While I worked as a Business Analyst, we tended to assume we knew everything up front. Therefore we never talked about learning as the development of the product evolved. As I mentioned earlier, the process was heavy, which means releases took long to happen. On the other hand, a Product Owner must accept that there are many details we don’t know, that’s why we need to release new increments as often as possible so that we receive feedback and adapt the direction.
Responding to change over following a plan
Scrum is an empirical process, which means we accept we don’t have all the answers upfront. We accept we build knowledge as we gain more experience. Therefore, building small cycles increase the chance of learning faster.
Learning fast was a significant change to me, it took a while to get used to it, however, now I cannot imagine working as I worked before, there are endless benefits with smaller cycles. The biggest benefit for me is avoiding waste since we focus on smaller increments, then we receive feedback and adapt the direction quickly.
Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.
The transition from Business Analyst to Product Owner can be quite smooth if we understand what we need to avoid and what we need to learn. Be sure that as a Product Owner:
- Communication is the most important part; forget about extensive documentation.
- Be part of the team, spend at least 30% of your time with them.
- Use the empiricism in your favor, accept you don’t know everything upfront.
- Learn constantly with the team through collaboration.
- Be ready to make decisions as well as be accountable for them.