6 errors to avoid as a Product owner in a Scrum framework 

Delivering a software solution for an industry is a difficult task to achieve. Feedbacks occur from multiple people; the delivery is directly related to the production and there are many factors to consider when starting the conception of the features. 

Most of the time, Projects in a context that complex are managed with a V-cycle management. Very powerful in the 80’s for software deliveries, this way of working is much more sequential than iterative.  

Far from the V-cycle way of working, being part of a Scrum team as a product owner might be one of the greatest challenges you could have in a tech company. Of course, it implies working on projects or products compatible with the scrum framework. But this compatibility is slowly reaching fields outside of the software development context. 

Either looking for a small introduction to the Scrum Framework and precisely the job of Product Owner, or a small wakeup call for any advised and confirmed Product Owners, here are 6 errors you should avoid if you are working as a Product owner in a Scrum team. 

Scrum Framework  

So why do we use Scrum? What is it?  

For anyone familiar with Rugby, a scrum means going as a block as far as possible to gain ground and gain advantage against the other team. There are no more roles, wings, forwards or backs, but a stack of players united together and walking towards the same direction.  

This might be astonishing to talk about Rugby in a technical software article, but the Scrum framework is coming directly from this term and this approach.  In the 1990s, developing and maintaining product for the large market of software development was very difficult, especially working with the V-cycle. Software solutions need to evolve to keep up their features and requirements. V-cycle is a powerful tool for project management, but it also requires a strongly defined need, and is way more limited when evolutions are required in the middle of the project. Most of the projects were initialized, planned, started, and while going through the quality process, cancelled. The time needed to finalize all the different actions was too long for the company to earn from the value they created. The specifications were constantly evolving and the final product delivered was often not conform to the new standards asked by the customer. Knowing this main problem, a small group of people decided to create a unique framework, in the Agile philosophy: Scrum. 

“Agile is an iterative approach to project management and software development that helps teams deliver value to their customers faster and with fewer headaches. Instead of betting everything on a "big bang" launch, an agile team delivers work in small, but consumable, increments. Requirements, plans, and results are evaluated continuously so teams have a natural mechanism for responding to change quickly. “

What is the goal of Scrum ? 

Briefly, the Product Owner acts as a big translator of the product needs for the development team. As a Product Owner, your goal is to fill in the gaps between the main stakeholders and the development team, using the Scrum Framework. Your role is  key to the overall understanding of the needs within the team. 

The main tool of the product owner is the backlog. He is the one responsible for it and has a strong control of what is inside. This backlog is here to define every task, issues, user stories that should be implemented in the future of the life cycle of the product.  

6 errors to avoid as a Product Owner 

Number 1: Splitting Time between this role and others 
 

As the Scrum framework defines it, a Product Owner can also be part of the Development team. Sometimes, Product Owners are shared between different products or Sub-Products.  It can work very well if it has been agreed with the Scrum team, but has to be done carefully with the managers.  

Being a Product Owner means being at the entry point of the Scrum development of new valuable features. The main quality of the Product Owner with the stakeholders is the problem analysis.  
Albert Einstein once said:  “If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and five minutes thinking about solutions” 

As a member of the Scrum team, one of the values you agree on is to enhance the team and the product at the same time and level.  

Problem analysis, backlog sorting, explanations for the development team and events preparation require time. Some managers could see in the Product Owner a part-time job, whether it is the case or not. Spending time as a Product Owner is directly linked to the product itself.  

Being able to know the time to allocate to your activities as a Product Owner is required. It is important once in a while to think about the allocated time you have to work as a Product Owner and fill all the functions required by the role. Despite being a source of stress, not having enough time in your role directly influences the whole Scrum team and will bring more difficulties to the project.