Team setup:

We are primarily an IT development team of .Net+Java developers who work respectively on components based on these technology stacks only. About few weeks back our team has been asked to follow agile scrum as an organizational initiative. As part of this my team has started having daily scrum standup calls. We also have planning meetings and retrospective now. We do not have dedicated scrum master and product owner in the team however we do have a ‘traditional manager’. We also do not have Kanban board to regularly update the task status. Our team has one confluence page where all tasks are listed. Mostly(for last planning meeting 16 out of 18) tasks are one liner and do not have subtasks even if they are as long as estimated for 5-10 days effort.

Problem(In my view, many team members do not agree to this):

What happens in absence of a Product owner is

  1. When we go to planning meetings we first start give priority to the tasks as a team based on those one liner task descriptions which in some cases are explained (but not documented) by member who has worked on similar tasks earlier. For some other tasks, we say we are still waiting for requirements.
  2. As there is no prior analysis of tasks we waste too much time in priority discussion and estimations.
  3. As these meetings are run by ‘manager’ we still plan everything based on task-people mapping rather than a general estimate.


Whenever I raise above points in meetings, based on my previous experience of agile scrum methodology, I am opposed by almost all team members saying “we will improve in long term, we have just started”. My question is: Is it ok not to have a Product Owner and being dependent on each individual to volunteer to fill details of task(create user stories) on runtime during planning meeting even if it results unclear requirements even after of planning meeting?

6 Answers 6


The short answer to your question is: No, it is not OK to not have a product owner in Scrum. I'm sure there's a team out there that has done it with some success (there's always the exception to the rule) but it's a critical part of the whole Scrum Team. Scrum is meant to be one framework that you can use to be more Agile. If you look at the Agile Manifesto and the associated 12 principles, the product owner is how Scrum addresses many of them. For example, much (not all) of the Customer Collaboration is accomplished through the Product Owner. Also, the 4th Principle is:

Business people and developers must work together daily throughout the project.

I don't see the business involved at all in your question. There are, of course, other ways to be Agile beyond Scrum and, if you were really determined, I'm sure you could account or a lack of Product Owner (though it would probably be more difficult than simply having a PO).

One thing you probably have to consider though, as a member of the team, is that if your organization gave you the directive to use Agile and Scrum, but didn't make Product Owner or Scrum Master roles, they may not actually have much interest in doing it. I fully encourage your team to strive to be as Agile as you can inside of the context of your team, but if the organization doesn't really have the desire to be Agile, don't frustrate yourself with it.


"Three bloody roles, Scrum has, and only three. If you can’t get that right, don’t call it Scrum, OK?" - Ron Jeffries (one of the original agile manifesto signatories).

The Product Owner role is critical to the success of Scrum. They are responsible for providing a business focused and consistent view of the requirements.


Nokia test is a good metric to use for beginning Scrum teams

Is it ok not to have a Product Owner and being dependent on each individual to volunteer to fill details of task(create user stories) on runtime during planning meeting even if it results unclear requirements even after of planning meeting?

Take a look at Question 4 in the Nokia test. As you can see, You do need a Product Owner. In addition to working with the team to write user stories and acceptance criteria, the PO is also needed to fill out the backlog, prioritize the stories and create a release roadmap.

You can use this Nokia test which also includes Jeff Sutherland's scoring system to objectively measure where you are as a minimally compliant Scrum team. At the end of a sprint you can set up a Sprint Retrospective meeting and do the following exercise:

As suggested in slide 2 let each person on the team take a sheet of paper and score the questions on a scale of 1-10. Then you can tabulate the scores to see where your team stands. For the 9 questions, the maximum score possible is 90. Jeff says that many in his CSM classes start out with a score of 40. You can use these scores to agree on what incremental improvements you can make in the next sprint to move the score up. And review your progress in the next Sprint Retrospective and so on.


My first immediate thought is 'how well will the team improve' if you don't have retrospectives? now to answer your question - no it's not ok not to have a product owner - scrum framework is fairly lightweight - but one thing it states is that you have a scrum master; a product owner and the team. Yes a member of a team can be scrum master; but you really should have a product owner who can: * understand the needs of the business * be the sole arbitrator of the priority of the tasks * be the voice and source of requirements and be able to answer any questions relating to it

Sounds like the team as a whole is trying to fulfil this role - and the lengthy discussions on priority are due to the fact that there is no sole arbitrator and some are left as 'waiting for requirements'

the saying goes 'scrum' is easy to understand - but hard to get right

I think you're on the right track, asking the questions you ask - but what your team is doing - should not be called 'scrum'

if it's of comfort - a lot of teams start off like this - doing a little bit from scrum and slowly get more scrum-like. Usually because there isn't enough buy-in from management. Sounds like you've got the buy-in from management - but a facilitator would go a long way in starting you off in the right direction


The Product Owner is absolutely mandatory to have when using Scrum. Your organisation may not understand the benefits from the beginning, but you need to fight for it every sprint.

The Product Owner is a part of the Scrum Team (not to get mixed up between this and the Development Team which is part of the Scrum Team as well). The PO brings insight to what the product is trying to achieve thus increasing the value of the product. They works with the business side of the company (if not actually in the business side) to gain knowledge on how to improve the success of the product. They will be the front line to set the business justification as to why certain features are developed. These may include such elements as UX, information architecture, text (wording) content, and how customers are using your product to their specific needs.

Most importantly, the are the entrepreneur of your product. They set the vision of the product without having to worry about how they are technically implemented. They shouldn't have to worry about the technical constraints but at the same time must work with the Development Team on how to come up with the best solution to the given situation. For example if there is going to be a crucial marketing event or community gathering, and there is an opportunity that is too valuable to miss. They don't need to know what protocols that your components are using, and what the server environments are.

The point you made about your company just starting out in using Scrum is important. In my personal experience, transitioning into Scrum is not easy. It takes a lot of studying and arguing (and studying how to argue). It may not be perfect in the beginning, you must improve with each sprint. Maximise on using the Sprint Retrospective.

Things to you might want to highlight:

  • Quality of delivery (delivered stories vs. accepted stories)
  • Effectiveness of planning (planned stories vs. delivered stories)
  • Team's velocity

Based on your description, it definitely sounds like having a dedicated PO would bring a lot of alignment and effectiveness to the team and value they deliver, but (stepping outside of "pure scrum" and into "agile") I would also disagree that a PO is mandatory; plenty of startups and small/scrappy teams use scrum but don't have a PO. Instead, they focus on deeply understanding value for their users, establishing a strong and cohesive vision, aligning on that vision, and general consensus on priorities, which is what a PO basically brings to the table.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.