How much time should a PO spend with the Dev Team?

Last post 09:35 am January 10, 2014
by Sandeep Kamat
11 replies
11:39 pm November 14, 2013

If someone were to ask how much time a PO should / expected to spend with the Dev Team, how would you respond?

12:57 am November 15, 2013

A Product Owner should be committed to the delivery of product value, and should spend enough time with the Development Team to meet that commitment.

01:13 am November 15, 2013

Others with more experience than me could advise better, but...

I would respond that it's important for the PO to be available to the team on demand, rather than focus on how much of the PO work week will be spent working directly with the dev team.

The more time a PO spends on grooming the backlog the less time (in theory) would be needed with the team. This depends on the team.

For a large dev team (9) I it could be full time or close to it.

For a small dev team (3) it could be less than 25%.

01:14 am November 15, 2013

Ian's answer is better... as much time as it takes. :)

02:07 pm November 18, 2013

What if the question changed slightly to "How much time should the PO spend with the Dev Team during the dev cycle?" -- would there be a change to the answer? How would you respond?

06:23 pm November 18, 2013

Ian's answer still valid. My answer was during the dev cycle. It's about availability rather than blocking off time.

Availability of the PO/business decision maker is a common problem. We're facing this now. Our PO is an internal, but the person they have designated as the decision maker and provider of answers to functional questions is quite senior. Needless to say, our questions have gone unanswered and there have been delays as a result. Until our client designates someone who has the availability to quickly respond to questions and has the authority to make decisions (which can still be changed by seniors in future sprints), further delays and push backs of the live date are inevitable. We need to help business understand the importance of quick answers and decisions in the development process.

06:15 am November 19, 2013

If someone insisted on asking "how much time" I'd have to respond that the quality of time matters rather more than the quantity.

This "quality" is partly about making sure the PO role is filled by the right person. Yet even if that is taken care of, an hour in a two-week Sprint might be better than two hours, if it is spread evenly over the iteration and not bunched up into one session.

08:15 am November 19, 2013

Agree with Ian, just enough time to fulfil his commitments.

05:32 am December 3, 2013

Just enough time to keep them going without any delay in response from PO on requirements clarification. Its his product so he should ensure his 24X7 availability :-)

If Dev team has to wait for 12 hrs because of the remote PO then it won't work.


04:23 am December 16, 2013

Enough time is when the PBI done by the Dev Team are accepted by the PO during the Sprint and in the Sprint Review meeting.
If the PO doesn't spend enough time, he will probably be disappointed by the PBI demonstrated by the Dev Team and will tend to rejected the PBI.

05:46 am December 16, 2013

> We do estimate by "effort" also. It is a way for us to estimate "everything" :
> dev effort ; test effort ; doc effort...
> It is very common to have something easy to dev and difficult to test or the opposite.

The work an agile team does is indeed varied, and some of it can be unusually demanding, even if it is not particularly time consuming. Effort doesn't really correlate to time.

09:35 am January 10, 2014

I agree with most of the previous answers. Being responsive to the Dev Team questions is most important. I have seen a 10 dev team members to 1 PO for a product that is in maintenance mode. For active new development the ratio might be even lower. Besides being present in person other channel of communication should include email and IM. PO will also need to attend 30 mins to 1 Hr user stories clarification meetings from time to time. Besides this, the PO should be able to effectively carry out the other responsibilities listed in the Scrum guide