Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

migrated from stackoverflow.com Jul 7 '13 at 16:48

This question came from our site for professional and enthusiast programmers.

6 Answers 6

up vote 1 down vote accepted

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.

share|improve this answer
    
"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 '13 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 '13 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 at 21:59
    
@mhaller: Absolutely, the backlog should be available to the whole team pretty much all the time. –  Bryan Oakley Jul 31 at 22:31

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 customer and/or user. However, the rest of the team is responsible for ensuring that the stories 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 and even avoided.

Remember that the Product Owner is the voice of the customer (and/or user) 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.

share|improve this answer
    
I think this nails it. –  Sklivvz Jul 8 '13 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 '13 at 4:43
> 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.

share|improve this answer
    
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 '13 at 15:30

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.

share|improve this answer
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. –  Loki Astari Jul 7 '13 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. –  Loki Astari Jul 7 '13 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 '13 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 '13 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 '13 at 2:30

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

share|improve this answer
    
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 '13 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 '13 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 '13 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 '13 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 '13 at 0:28

good question, really good question, i give you that.

that's kinda problem almost all of us encounter in our daily routines, (not daily but ... )

i don't know about your current job position but it seems you could make decision.

and i'm sure you already know many thing that i want to mention, it's just from another point of view:

Money / Time . base on my experience, Money and Time are you friends.

i could imagine 3 scenario here:

1: if you didn't decided on feature so logically you didn't decided on money either. and if you talk about money every time they talk about new feature, you are winner. (if it's hard for you, pass it to someone else like financial manager/consultant or someone else so you could get off the hook)

2: you fixed the payment amount, but for some reason your agreement is open ( Customer has higher hand),in this situation cry every time he/she wants to add or change something (and start it at the first step), you should put pressure on him/her too, with what? you hard work, lack of time, other better projects with someone else, i will do this JUST FOR YOU AND FOR YOU NOT ANYONE ELSE, something to mention that YOUR DOING A FAVOR, keep it in mind: IT'S A FAVOR THAT I'M DOING FOR YOU, AND YOU CAN'T ASK FOR FAVOR EVERY TIME YOU WANT

3.your boss hired you, and you are working for a big organization, and they expect you to deliver the product on the schedule and they want to be able to change it's specification every time they want, it's the easy one, increase the time line in front of them every time they come to you (Gantt chart probably) something like this: OK, it's very good point and we should do that, so it takes 10 day to complete and based on our schedule it will be completed in XXX , but if you want it sooner, we should delay XXX feature, which one you prefer?

and do not forget: "Scrum is an iterative and incremental agile software development framework"

Don't miss "iterative" part. you decide what to do (base on your schedule, team ability , etc ...) for just one ahead "iteration", when you decided it's good to go, no change is acceptable in middle of iteration. try to put this in their mind.

As product/team manager, you should believe: it's another war for you, Customer is not friend, he/she is an enemy, you should hold him/her back from your base: Defend the base

and you have two sword ,Just two: Time and Money

Attack All the time. Don't stop, even when everything is fine, Be Polite , listen to them and act with justice but Attack in every position, just allow minimum needs to pass from your guard.

"Money is not enough, Budget will increase dramatically, time is not enough, it's not possible to deliver the product on time, why did you want this when we don't have enough time/ money/staff/equipment."

Money And Time:

Use them wisely brother otherwise you are doomed in iterations.

==== it's about communication skills more than technical abilities. i took a class long ago to be able to handle these kind of situation. class title was: "how to be a better negotiator", and it's really helped.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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