3

I work for a small software company and I am the Scrum Master. In this company we have a small group of people who consist our StakeHolders. To represent the StakeHolder's interest the stakeholders choose one of themselves to be product owner. To me this is all fine and dandy as long as we have some one who is responsible for what the development team works on. Unfortunately the company is maintaining several projects at one time and there is always competing items for development time.

Here is my question, at what level does the product owner prioritize work? My product owner likes to say we need to work on Large Project A, Large Project B, Small Project C. The time line for these items are due in 2 months. A the Product Owner considers that to be the priority of items.

Alot of the resources I have read about Scrum says the Product Owner organizes work by features. Supposedly, a great product owner will organize items in priority to maximize the amount of work the team can do. From what I read, it seems to me that our product owner is only a Product Owner in name, where he is actually just a StakeHolder representing StakeHolders.

If I am right about this, what is an effective way to correct the Product Owner and Stake Holder on his management style?

  • 1
    What problem is this behavior causing? It's best not to think of "doing scrum right", but to ask if this is actually a problem and if so, how to address the problem itself. – RubberDuck Apr 28 '16 at 3:00
  • 1
    The team is often very dispersed on their task, each member kinda goes off on into their own isolated sandbox. Since the team just works on a rather large not focused area. This has been leading to a significant amount of the stand ups being the equivalent to reporting in with out any actual interaction with other developers. It feels that this is problem? – Matt Wilkinson Apr 28 '16 at 4:16
  • 1
    There is a lot of red flags in your statements that make me think you are not even remotely close to the organisational rigour required for good Scrum implementation. The answers below should all be considered as they are all equally valid. Your PO does not maximise work for the team, the Development Team should have ONE Project, the PO prioritizes the backlog of user stories and the Developers choose which user stories to work on according to their Definition of 'Ready to Play' and PO consideration...this is just the cultural tip of the Agile iceberg. – Venture2099 Apr 28 '16 at 10:12
  • @Venture2099 I completely agree with you on this. However, every time I bring up these items to the PO he gives me a speech about how this is a small company and we do not have the resources to only focus on one project. So the team is constantly being pulled off of current projects, and being put on paid development such as drivers and etc. – Matt Wilkinson Apr 28 '16 at 13:49
  • @MattWilkinson - there are quite a few posts here that do a great job of explaining that Agile values / Scrum framework requires buy in at all levels of the organisation (Dev Team right up to C-Level or Strategic). If you don't have that then I don't envisage much success in changing the organisation. A bit of a bleak assessment but it's an opportunity to sell the real benefits of Agile values if you have some allies above the PO. – Venture2099 Apr 28 '16 at 15:45
4

Scrum is at its most effective when there is one backlog and one Product Owner for a delivery team.

The backlog is designed so that the work that is about to be started is defined at the user story level, which is convenient for the delivery team to work on. But the backlog may also contain planned work that is several weeks or even months away. This work can sometimes be defined quite roughly and is represented by 'epics' or 'themes'. These are probably the closest thing in Scrum to the 'Project A', 'Project B' and 'Project C' that you mention.

The idea is that the Product Owner is continually refining the backlog. They break down the roughly defined work in to more concrete user stories in a just-in-time fashion. Such that the work that is about to be started is nicely defined, but future work may be less clear.

Although the Product Owner is responsible for the backlog that does not mean they are the only person who works on it. It is quite common for the Scrum Master and the delivery team to sit with the Product Owner and help them with the task of breaking future work down in to user stories. This is particularly common when the Product Owner is not very experienced in the role.

My first recommendation would be to suggest that the person who is currently in the Product Owner role gets some training. Product Owner certification is ideal and is usually just a couple of days worth of training.

Secondly, have the Scrum Master and team work with the Product Owner to help them to break the ill-defined work down in to requirements that the team can work with. I would suggest you do this as a part of backlog refinement meetings that happen quite frequently. You may well find that once you have done this a few times the Product Owner starts to grasp the concept and will then do a lot of the refinement themselves.

  • 2
    Thank you for the robust explanation. I have suggested the backlog refinement to our Product Owner before, he always just tells me that it is his role to organize what areas the team is working on. I think you hit the nail on the head that the Product Owner could use some training in his role from what the team should expect from him. I am sure I could use some more as a Scrum Master. I will suggest the team help the product owner in creating better User Stories during backlog refinement thank you for your response. – Matt Wilkinson Apr 28 '16 at 14:17
2

It seems that you have problem with coherent Sprint goal.

I do not know how the team uses Product(s) backlog but you should emphasize to the PO that the more coherent the sprint content is, the more efficient the team works. If each member works on his/her own item it is not really Scrum (I mean the origin meaning from Rugby). To take advantage of Scrum (framework) whole team must have the one common goal of the sprint to increase collaboration and self-organization.

One more thing. In the post you mention:

Supposedly, a great product owner will organize items in priority to maximize the amount of work the team can do.

The product owner is here to maximize ROI (return on investment) of the project not the amount of work. PO should order the product backlog so that the project delivers the maximum possible value every iteration (so that team works on the most important items first).

1

As I understand from what you provided so far, your symptom is:

there is always compete items for development time

This is in itself a very normal challenge of (software dev) life, which the product owner is responsible for taking care of. So far you seem to be on the right track, just the problem seems to be that you have multiple projects for one team, with dedicated people in the team for each project. Now, in case the various projects don't have any interdependence, I would recommend to split up the teams in smaller ones - each consisting of the dev team that works on one product backlog for one of the projects you have.

If splitting up the team is not an option (because of dependencies), you need to include all projects into one backlog for the one team you have. Then it is again up to the PO to decide about priorities inside that backlog. And yes, it is normal that this migth be challenging for the PO. In general, you can have one backlog for multiple teams - but you can not have multiple backlogs for one team.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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