Top 5 Mistakes New Product Owners Make in SCRUM Teams and How to Avoid Them!

When you are a new Product Owner (PO), and just gaining real experience as a PO, there will be some assumptions you make or perceptions you might have developed leads to some mistakes, that may create some level of chaos in the team. Do not fret. It happens to everyone.

However, the key is, as a PO you should have an open mind to accept and learn things when you are making a mistake. While the SCRUM is great and helps teams deliver value, but when the rules aren’t followed, it can hinder progress and frustrate team members.

Here are the Top 5 mistakes to avoid for a PO in his/her early days as a PO in a SCRUM team.?

1. “Will discuss Everything in that Daily Call. Why a Separate Call?”

Please understand that Daily SCRUM calls should run for the least amount of time (Standard 15 minutes) and the purpose of a daily Scrum call is to synchronize the team, share progress, and identify any obstacles to achieving the sprint goal. It fosters collaboration, transparency, and quick problem-solving. Daily SCRUM call is not a call to discuss anything that you as a PO want to discuss. You as a PO should schedule a dedicated call to discuss any other topics in detail. Hence, before you get into a SCRUM team, have a clear understanding of SCRUM events, rules and practices—more importantly intensions behind them.

2. Getting frustrated due to lack of clarity early on or before the Sprint

Expecting complete clarity beforehand or as soon as a backlog item is created requires a mindset shift for a PO. In Waterfall methodology, you may get full clarity when you document requirements, however, in SCRUM, you have a Story planned and put it in a backlog, but still may not have full clarity till the Sprint dates are near. No one in the team also expect an Acceptance criteria from a PO at this stage. This requires a discussion, and collaborative effort between stakeholders and team to get that clarity and then finally arrive at an acceptance criteria. The teams should embrace uncertainty and foster collaboration between the team and the PO to refine and finalize requirements iteratively. This allows for flexibility, adaptability, and a quicker response to changing needs or insights during the development process.

3. Not breaking down backlog items into small pieces properly.

Due to inexperience or lack of skills (as in this context the PO is new and still learning) sometimes the PO prefers to work on overly large backlog Items that increase complexity and hinder incremental value delivery. Sometimes, the PO is not able to understand and visualize why this story is large for a particular Sprint and has to be broken down. This is where a new PO always collaborate with the team and stakeholders. He/she should take help from the team to break down the backlog item into several smaller, manageable tasks suitable for a single Sprint. As a PO you should involve customer stakeholders in the process or at least clearly communicate the same to them. Always, a PO should enable and help the team to focus on delivering incremental value with each Sprint.

4. Not respecting Sprint Goals

Many times, a PO wants to finish things fast. But it won’t happen that way. There will be hurdles. Just if you want to finish a few things fast to impress stakeholders or for the sake of keeping the backlog clean and tidy, you should not force the team to carry over unfinished work between sprints. Always focus on Sprint's goal. Have a clear plan and idea about the same and be committed to achieving the sprint goal (ideally). However, one thing to keep in mind is that this needs interaction with stakeholders as well to understand any business criticality of the item—because any business-critical things need to be prioritized. Hence, always, prioritize completing work within the Sprint and minimize carrying over unfinished tasks. Aim for a potentially shippable product increment by Sprint's end—this should be your simple goal in your mind as a PO.

5. “SCRUM MASTER will take care. Will Ask SCRUM Master”

Before getting into a SCRUM team, you need to know key aspects of SCRUM for sure, more importantly, the roles. Scrum Masters are servant leaders who are the facilitators and the people who ensure that Agile/SCRUM principles are followed in software development teams, fostering collaboration and removing impediments to progress. They guide the team in implementing SCRUM practices and help maximize productivity. They should be not bothered about requirements, assignments, approvals etc. SCRUM Master is not your manager. His/her focus is different, as stated earlier. Thinking “SCRUM MASTER will take care. Will Ask SCRUM Master” or SCRUM master is my manager fosters dependency on the Scrum Master for task allocation and decision-making. So, as a PO, know it clearly—understand SCRUM Master's role as a facilitator, not a manager. You too take ownership of your tasks and responsibilities and also encourage team members to take ownership of their work and foster direct collaboration.

SCRUM team is a self-organizing team focused on delivering value, not just a deliverable. Hence, owning things and delivering a “value” should be your mantra, when you are in a SCRUM team!

?