4

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?

5
  • 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
    Commented Apr 28, 2016 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? Commented Apr 28, 2016 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. Commented Apr 28, 2016 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. Commented Apr 28, 2016 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. Commented Apr 28, 2016 at 15:45

6 Answers 6

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.

1
  • 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. Commented Apr 28, 2016 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.

1

what is an effective way to correct the Product Owner and Stake Holder on his management style?

You’ve not said why you want to do this, consider what issue is being created as a result of this management style, that will be your leverage to correct.

Having said that the key thing to remember is that while the PO is responsible for the backlog, they are not the only person who has an input to it. The scrum team should all be providing input which the PO takes into account. Is that going on here? Doe the PO have a PSM certification?

As other shave said, it doesn’t really work to have a single scrum to be working on several projects, consider breaking up the team. Appreciate this is a small company but, and again training might help here, but scrum is set up that way for a reason. Give priority to the project in need of it, then move onto the next project.

In terms of the backlog, the PO must organise it to for best ROI, you’ve not said if that’s happening here, because if it isn’t, then perhaps you can demonstrate to them how it could work better by providing; a better structured backlog, some training etc

To summarise, it appears you don't have a scrum, instead you are using the titles provided by scrum to continue standard practice. This can come about from a lack of training however it is also due to a lack of standardisation between organisations on agile concepts and delivery.

0

It seem to me that the entire organization from the top to the scrum team need to learn the concept of tasks and self-organization.

It's not out of place for an organization to have multiple projects running at the same time. However, priority needs to be given to say project according to their value creation and urgency to the organization.

It's not healthy that the PO pulls from one source of development team and assign to other ongoing project. What could be best done here is from the PO to split the development team into the number of projects running concurrently and assign each dev team to a product so the team members can understand their deliverables. Project A for instance should have it's own product backlog and PBIs should be refined and moved to prioritized sprint based on the collective agreement of the entire scrum team and the value that such items brings to the table. The wheels should be reinvented for other projects as well.

It is also worthy of note that a scrum master can only manage a scrum team at a time, micromanaging multiple team's within an organization is not a good idea, instead, the scrum team should finish a project before choosing to start another one.

1
  • "It's not out of place for an organization to have multiple projects running at the same time." - Significant understatement - that is normal, and the role & responsibility of that layer of management is to allocate resources among those projects. The PM/scrum team's responsibility is to inform the PO of the impact of those resource changes on the delivery of the project. "self organization" is a lovely idea, but it isn't realistic for the Board of Directors to yield to a self organizing team
    – MCW
    Commented Aug 1, 2022 at 11:22
0

You have a problem... the product owner is not a real product owner, so it does not know anything about agility, so scrum will never work that way, unless you find a proper product owner.

As the Scrum guide says, management, stakeholders in this case, help the company to implement scrum, but are not part of it, even more in this case, when the person has no clue about agility.

The mindset behind of what you describe is not meant for Scrum, instead, use Kanban and you will start seeing the benefits. The company you work on are not focused on something specific, like scrum enforces (goals)... their goal is opportunistic and purely based on revenue probably, so they pull the devs wherever they need to achieve business results... Scrum is not meant for these situations I'm afraid.

You are saying it... they care about the WIP and that's a Kanban thing. And they might see something is needed because they haven't heard about it in a long time... so Kanban again!

Stop doing Scrum and move to Kanban... everyone's lives will be easier.

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.