4

For the last 3 sprints or so, I've observed our Product Owner suddenly shoving new stories -- stories not previously in the Product Backlog -- at the top of the Product Backlog.

Because of this, the existing items in the backlog never get worked on. New stories continuously take over the helm and make into our Sprint Backlog.

My question is - how much can the Product Owner really shake up the Product Backlog? Is it really fair game to ignore what's already in the backlog and keep on shoving new stories at the top?

I've tried to argue that this is hogwash, but I often hear counter-arguments such as "adapting to frequently changing business needs," "we're moving so fast - we're super agile" and I don't know what to say to those arguments, although I feel it is not how Scrum was meant to be.

EDIT: I understand that the product owner owns the product backlog. What I am observing at my team though, is that the PO constantly puts new items at the top of the backlog, ignoring the existing backlog items completely.

For instance, say we're building a car and PO creates 10 stories to make it happen. We decide to take on 3 stories in our sprint backlog - thus 7 stories still remain in the product backlog. Everything is good so far.

At the next sprint planning, however, the PO now claims that we need to build a baseball bat and creates 5 stories around that - which are then placed at the top of our backlog (i.e. highest priority); nevermind those car stories we already had in the backlog.

Improve this question
0

5 Answers 5

Reset to default
2

It sounds like the PO is just doing their job. It is their job to know the needs of the customer, and to balance those with the needs of the business. They are the ones that decide what the company will ultimately sell. If they switch from automobiles to baseball bats, presumably that's because they've decided bats are more important. If they are more important, why do you want to continue to build an automobile?

If the team is bothered by this, talk to the PO and tell them your concerns. Again, they are just doing their job, but they should know the effect this churn has on the development team. It's hard to focus on a product when you're constantly switching products back and forth.

Improve this answer
4
  • "If they are more important, why do you want to continue to build an automobile?" - you certainly don't. But I also feel that there's something wrong when we're building a different product each sprint, without finishing any of them. It tells me that proper due diligence is not performed by the PO to really understand what the customer wants, and I'd be curious to know how Scrum as a framework handles that if at all.
    – user226825
    Jul 9, 2013 at 15:16
  • @user226825: you could be right - you might just have an incompetent PO. That's not the fault of scrum, or of your development team.
    – Bryan Oakley
    Jul 9, 2013 at 15:34
  • the product backlog should be known to the devs. if there are only new stories and no known stories on the day of planning game, dev team had no time to think about the stories up front. that's bad. a better way is to have the team know about backlog items and move them nearer the top if they become more clearer and more ready to be put into a sprint. if PO only adds new stories on the day of planning game, he may have no strategic vision for the product and reacts to short-term requirements. that's operative but not strategic.
    – mhaller
    Jul 31, 2014 at 21:59
  • @mhaller: Absolutely, the backlog should be available to the whole team pretty much all the time.
    – Bryan Oakley
    Jul 31, 2014 at 22:31
6 
> how much can the Product Owner really shake up the Product Backlog?

It is the job of the Product Owner to "shake up the Product Backlog".

In Scrum it is the job of the product owner to rank and prioritize the features in the Product_Backlog.

product owner and team agree what to implement in the next sprint and put these features into the Sprint_Backlog

You as a developer have to argue if you need technical features in the sprint log that the product owner doesn't see.

Improve this answer
1
  • It's not so much that the technical features are missing. It's more like, new stories show up out of nowhere for the devs to take on for the next sprint. Basically we have no backlog; whatever PO comes up with on the Sprint Planning day is what we'll work on for the next sprint.
    – user226825
    Jul 6, 2013 at 15:30
6

In traditional Scrum, the Product Owner is the person who owns the Product Backlog. This person is responsible for adding or removing stories as appropriate and ensuring that the list is prioritized based on the needs of the stakeholders. However, the Development Team is responsible for ensuring that the Product Backlog Items that are added are understood and good enough (complete, clear, testable, feasible, etc) to be estimated and delivered when they come up in a future sprint.

From your perspective on the development team, you shouldn't be relying on the product backlog. All of your actions - your requirements elaboration, architecture and design, implementation, and testing should be fully based on the Sprint Backlog. This is what gets fixed for a particular Sprint and changes to the Sprint Backlog should be minimized.

Remember that the Product Owner is the voice of the stakeholder for the development team. They are the ones who understand what the business need for the system is and what capabilities or features would have the most impact.

Warning signs to look out for would be the Product Owner attempting to change the Sprint Backlog or having a Product Owner that is out of touch with the needs of the business or user base.

Improve this answer
2
  • I think this nails it.
    – Sklivvz
    Jul 8, 2013 at 9:06
  • I agree that the devs should focus on the Sprint Backlog; however we aren't blind. When the PO constantly pushes new items as our 'highest priority' it is only natural for the devs to question, "what happened to those items remaining in the Product Backlog that you said were important last time around?" In short, I am starting to realize that our team really doesn't have a Product Backlog - whatever comes to PO's mind will become the "Product Backlog" for the next sprint.
    – user226825
    Jul 9, 2013 at 4:43
5

how much can the Product Owner really shake up the Product Backlog?

As much as he likes.
It is the "Product Owners" job to represent the user and get them what they want.

Is it really fair game to ignore what's already in the backlog and keep on shoving new stories at the top?

Sure is.
If the old stories are no longer relevant to the user why build them. You only want to build what is important to the user. But be careful. A story is supposed to be a user action. You should be able to describe a story in terms of an action a user does (no technical details).

I've tried to argue that this is hogwash

It is the job of the "Scrum Master" to protect the developers from flippant change.
It is the job of the "Scrum Master" to pick what makes it into the sprint and protect the developers from the "Product Owner" and make sure the technical part of the project work. This means he should be picking items to form the architecture first. He should try and deliver some user stories but the ones that make sense (trying to respect the Product Owners priority but he does not need to stick to it 100% if that does not make technological sense).

Note: As pointed out below my definition of "Scrum Master" here may not be fully standard. I was simply using it to point out that it is not the Job of the PO to pick tasks for the scrum backlog as this is a technical in nature (and the PO being a chicken has no voice in the sprint planning). It is the job of the team to pick what goes in the sprint backlog as they are technically inclined and understand how components will interact. They will be heavily influenced by the priority in the product backlog but that is not there only consideration they use when making technical decisions. My use of the term "Scrum Master" is heavily influenced by my experience where the "Scrum Master" is usually the technical or team lead (usually a senior dev with the clout/fortitude to stand up to management who tend to be pushy when they can get away with it) this of course is not required by scrum.

-

but I often hear counter-arguments such as "adapting to frequently changing business needs," "we're moving so fast - we're super agile" and I don't know what to say to those arguments,

These are good arguments. But make sure

  1. You are talking about true stories
  2. Your architecture takes priority over user interface

although I feel it is not how Scrum was meant to be.

Scrum is meant to allow you to react quickly.
But during a sprint there should be no change to the sprint backlog. And make sure your sprints are of reasonable length: 3 to 4 weeks. That should give you a chance to finish a reasonable small story or build the foundation for a large story.

Improve this answer
38
  • 3
    @user226825: So. Since you have not done any work on jobs in the product backlog what does it matter. You do the most important story's that the PO wants (making sure architecture is not impacted). The problem with developers is they want to develop "cool" stories. The job of the PO is to make sure the work you do is relevant to the people that use the software. The job of the SM is to make sure the architecture is not compromised by the PO, make sure the developers do appropriate jobs.
    – Martin York
    Jul 7, 2013 at 4:49
  • 2
    @user226825: Once you have built the bike you can go back to building the car. But what is the point in building a car when the user wants a bike. That is why you have demos. So the user can see what you have done and tell you that you are on the wrong track and building a car when he only wants a bike.
    – Martin York
    Jul 7, 2013 at 4:53
  • 1
    I've never heard it described as the scrum master's job to pick what stories go into the sprint. Can you cite a reference for that? I thought it was the PO who decided what does in the sprint by prioritizing the backlog.
    – Bryan Oakley
    Jul 7, 2013 at 17:40
  • 1
    @LokiAstari Every user story in the product backlog should be user facing functionality. I don't know what you mean by the architecture being a mess if you don't do them. If a feature is more important to the customer, you implement it sooner. If that means you need to incur technical debt, then you incur that technical debt and manage that risk by budgeting refactoring in later, usually by giving user stories a greater number of story points to account for refactoring, updating tests, and executing more regression tests.
    – Thomas Owens ♦
    Jul 8, 2013 at 1:35
  • 1
    I understand where you're coming from. Your answer seems to be geared more toward your personal experience than toward how scrum is supposed to work. That's cool, and people may find your answer useful, but I think as it's written it may give a wrong impression to those who are trying to understand how scrum should work.
    – Bryan Oakley
    Jul 8, 2013 at 2:30
1

Great answers here and I do agree that it is the PO's job to do that as he/she has to determine the best possible ROI for the product. He/she would be doing the wrong thing by building less valuable PBI's.

However there are some fundamental rules.

  • The PO cannot change the current sprint by moving items in and out at whim.

  • When the PO adds a new item, the team has needs to estimate it and the PO needs to respect that estimate

  • The PO is then responsible for managing time, budget and scope (the magic triangle). i.e. if they add new items they have to come up with more budget or remove an equivalent lower valued item.

  • The PO is accountable to make sure the items have enough detail in them that the team can pick 1up in sprint planning. It should have enough information that the team can ask minor clarification questions. This is often a dysfunction in many teams where a long time is spent discussing what the requirement is, instead of minor clarifications.

  • The PO in grooming sessions should consult with the team and heed their advise on any potential challenges with new requirements, impacts or dependencies. This should help him/her order or make better decisions.

Is it the teams accountability and responsibility of defining what gets built or that of how it should get built? The bottom line is its not the teams decision or risk to take and the team should focus on delivery of quality items regardless of what they are.

Finally, use retrospectives to thrash out any concerns you may have

Improve this answer
5
  • Our team nails all the items. The only problem is, the contents of 'Product Backlog' flips so much from one sprint to another, that there is no continuity in our work. Hence I tried to get a sense of how much freedom PO has in modifying the Product Backlog. If the answer is as much as he/she likes, then it is Scrum's limitation to not being able to prevent the situation we're in from happening.
    – user226825
    Jul 9, 2013 at 4:41
  • Scrum is all about encouraging this situation to happen. If you're not building what the customer wants, the PO is obligated to change the backlog to deliver what the customer wants. Scrum is about optimizing for the customer, not for the development team.
    – Bryan Oakley
    Jul 9, 2013 at 11:10
  • @BryanOakley I agree if the PO is doing proper due diligence to understand customer wants. The frequency with which we switch products back and forth makes it harder to believe that that is the case, though. Does Scrum offer some guidance on this front?
    – user226825
    Jul 9, 2013 at 15:14
  • @user226825: if the backlog is changing frequently, that might be a sign that the PO might be doing something wrong. There's not a lot scrum has to say with respect to people who can't do their job. I guess the first step is to figure out if your PO is incompetent, or if he/she has good reasons for doing what they do. Answer that question by having an open conversation with your PO.
    – Bryan Oakley
    Jul 9, 2013 at 15:32
  • user226825, it does sound like the frequent change is impacting the team. Have a retrospective with the PO and thrash out concerns and try reach a balance where the PO has freedom to change but giving enough similar context to the team. As this is a self-organising team, ask the team how they can adapt to this situation and make it work. I recommend trying to align more with PO changes whereby things can be complex and unpredictable but not to the level where the PO is clueless. See if the PO has challenges whereby he/she is getting bad info and see what the team can do to help.
    – Brett Maytom PST
    Jul 14, 2013 at 0:28

Your Answer

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

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