Timeline for Scrum: How much can the Product Owner shake up the Product Backlog?
Current License: CC BY-SA 3.0
42 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 9, 2013 at 13:17 | comment | added | Loki Astari | @BryanOakley: Thanks for helping me walking through that. I appreciate the input. | |
| Jul 8, 2013 at 18:11 | comment | added | Bryan Oakley | re: "None of these are important to the customer.". I disagree -- all of those are important to the customer. If your storage costs go up, you'll end up passing that on to the customer, won't you? And surely your customer cares about software quality. And if your logging is buggy you might end up charging the customer incorrectly, and surely they care about that. If you want to count those as stories, that's the smart thing to do. It sounds, however, like your PO doesn't seem them as stories. You need to educate your PO, or find a way to work within their limited vision. | |
| Jul 8, 2013 at 18:07 | comment | added | Bryan Oakley | @LokiAstari: I'm not talking about my view. You're the one with a PO that seems to see everything only through the customers eyes. Again, my point is, if your PO doesn't understand the technical debt, one way to work with your PO is to say that for the first user story you're going to have to tackle some infrastructure changes. Personally I'm well aware of these types of stories because I'm a PO myself. My team doesn't have this problem. The right long term solution is to better educate your PO about the technical demands of software development. | |
| Jul 8, 2013 at 16:56 | comment | added | Loki Astari | @BryanOakley: I think your view on user is too limited. In real life we have competing priorities. The customer is always at the forefront of our thoughts. But we have other architectural concerns that have other users (Accounts/Management.etc) to make sure we build a product that is maintainable. | |
| Jul 8, 2013 at 16:54 | comment | added | Loki Astari | @BryanOakley: Our service is currently running on AWS when they shut down machines we create maintenance stories. We currently have $100,000 per month bill for storage so we have a story to reduce storage costs. We had a bug that has been fixed but we noticed some strange data so we have Data Quality story. We have a story to fix an issue with logging as this affects customer charging. None of these are important to the customer. We could just call them random tasks, but we count them as stories as they affect our velocity. Some of these will out way "Customer" stories and get into the sprint. | |
| Jul 8, 2013 at 14:43 | comment | added | Bryan Oakley | @LokiAstari: I think you are misinterpreting my statements. You seem to have a PO that is largely ignorant of the need for some improvements to your infrastructure. My suggestion for working around this situation is to simply make this work part of the first user story, if the PO insists that the first story is customer-centric. The team is responsible for telling the PO what it will take to complete that story. If "what it will take" includes setting up a testing infrastructure or an SCM tool or bug tracker or whatever, the PO has to accept that or be willing to negotiate. | |
| Jul 8, 2013 at 14:05 | comment | added | Loki Astari | @BryanOakley: Sure we could do that. If we did that we would have several sprints were we completed no stories and only did tasks (architecture).You seem to stuck in the mind set that the "customer" is the only user(and thus the only person that gets stories). I disagree with that concept. To me there are many types of user. The customer is the most important one but I have to serve all of them. I can only amass so much technical debt (As Thomas puts it) before it becomes unmaintainable and costs the company more than we make from the product so the customer is not the only user I worry about. | |
| Jul 8, 2013 at 13:42 | comment | added | Bryan Oakley | @LokiAstari: another way of looking at your problem is that the "stories" for tools and infrastructure aren't stories at all. Instead, they are tasks that need to be completed in order to complete the first story on the backlog. If the PO says "The most important story is X", your team simply needs to say "Ok, to complete X, we'll need a task to set up a build environment. We'll also need a task to set up SCM, and to run unit tests". Bottom line is, the team gets to decide how to fully implement the PO's top priority story, even if that means there are a bunch of one time setup tasks. | |
| Jul 8, 2013 at 12:59 | comment | added | Loki Astari | @ThomasOwens: But you did them first. Its a sprint and a story. We work on stories that will facilitate us doing the top priority story. Its not that we pick random stories we want to do, we work closely with the PO. But sometimes stories are just not doable at the current time; the architecture is not there to support it. There is not point in doing a story that can not succeed yet. Can't be that wrong. We deliver at the end of each sprint. We move forward rapidly and the software is well tested and maintainable with few bugs and neither our PO or customer are upset. | |
| Jul 8, 2013 at 12:43 | comment | added | Thomas Owens♦ | Those aren't user stories at all. That's infrastructure setup that should have been done in what I've always heard called "Sprint 0" or as a Spike facilitate the development stories. If you aren't working on stories that the PO (and therefore the customer or user) has prioritized, you are doing it very wrong. | |
| Jul 8, 2013 at 12:41 | comment | added | Loki Astari | @ThomasOwens: The first stories we did on this project were not in the top 100 of the product backlog. The product owner did not rate it as important at all. But the whole team insisted that it must be done first. 1) Story: Allow a developer/tester to build any part of the project on their machine/Test environment/Production using the same set of tools/commands /*long description about tools*/ 2) Story: Allow a developer to checks in code, so that it is automatically validated against unit tests and full system build by scheduled and validated against test data. /* Lots more detail*/. | |
| Jul 8, 2013 at 12:23 | comment | added | Loki Astari | @BryanOakley: I think you are talking about ideals that we should strive for while I am describing the reality of scrum in the real world. | |
| Jul 8, 2013 at 12:18 | comment | added | Loki Astari | @ThomasOwens: Yep. All stories are user stories. But not all users are customers. Not all stories can be done without infrastructure. Sure if you are writing a small web app or a desktop application then yes I am sure you can get away with that. In reality no. If you build big software it takes more though on the architecture. I have several stories at the top of the backlog that can not even be attempted (probably for a year) as we need underlying stories to work first. We have mocjed out the UI so that we can show what it looks like but real interaction is not going to work. | |
| Jul 8, 2013 at 2:30 | comment | added | Bryan Oakley | 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. | |
| Jul 8, 2013 at 1:35 | comment | added | Thomas Owens♦ | @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. | |
| Jul 8, 2013 at 1:22 | comment | added | Loki Astari | @BryanOakley: If I had product owners that were technically competent (or when they gain enough experience to understand the nuances of a large system) then I can see the role being extended in that direction. But until that point I can not see them directing architectural choices that would be discussed with the developers while working out tasks. | |
| Jul 8, 2013 at 1:19 | comment | added | Loki Astari | @ThomasOwens: I agree with your point on SM (see my note above in the article); And in a perfect world I would also agree on how the sprint backlog is filled, but in reality no. There are always stories that NEED doing that the product owner does not rate as important (as they are not customer facing). But in reality they need to be done because architectural they will be in a mess if you don't do them. | |
| Jul 8, 2013 at 1:08 | comment | added | Loki Astari | @ThomasOwens: In a perfect world yes. But in reality no. There are always stories that NEED doing that the product owner does not rate as important (as they are not customer facing). But in reality they need to be done because architectural they will be in a mess if you don't do them. | |
| Jul 7, 2013 at 22:49 | comment | added | Bryan Oakley | Personally, I think you are still a little off base. The modern definition of a product owner is more toward being a pig than a chicken. For example, see Building a better Product Owner and The dirtiest pig in scrum - the Product Owner as well as the section on scrum roles on wikipedia | |
| Jul 7, 2013 at 22:36 | comment | added | Thomas Owens♦ | The idea that anyone "picks tasks" for the sprint backlog is, based on my understanding and experience, incorrect. The sprint backlog is filled by taking the prioritized tasks from the product backlog (as ordered by PO) and the velocity from the previous sprint. The highest priority task is taken and moved into the sprint backlog until the size of the sprint backlog is equal to the velocity of the last sprint. The ScrumMaster doesn't have nearly as much active responsibility as you describe - the Scrum Master is only there to remove roadblocks that slow down or stop work from progressing. | |
| Jul 7, 2013 at 22:15 | comment | added | Loki Astari | @BryanOakley: Added a paragraph. | |
| Jul 7, 2013 at 22:14 | history | edited | Loki Astari | CC BY-SA 3.0 | added 731 characters in body |
| Jul 7, 2013 at 22:08 | comment | added | Loki Astari | @BryanOakley: I think you like playing with words: To me facilitator and coach sounds exactly like a lead. But sure I can see that he does not need to be part of the team. | |
| Jul 7, 2013 at 22:03 | comment | added | Bryan Oakley | The scrum master shouldn't normally be the team lead -- that's not how scrum works. The scrum master role is designed as a distinct role separate from the construction team, someone who acts as a facilitator and coach. If you're going to base an answer on a non-standard definition of a standard scrum role, you should put that in your answer. | |
| Jul 7, 2013 at 21:56 | comment | added | Loki Astari | @BryanOakley: Yes. I agree. I think that is also what I said three comments above. I am using SM in this context as a short hand for the team as the SM is usually (but not required) the team lead (or a member of the development team that talks to the PO). But I agree with your point. I just think we are arguing over wording. The point being that the PO does not decide what is in the sprint as that is a technical discussion. BUT he does influence it heavily by the ordering of the backlog. | |
| Jul 7, 2013 at 21:54 | comment | added | Bryan Oakley | I've never heard of a sprint backlog being owned by a scrum master, either. They can help a team do some prioritization, but they don't actually do it themselves. The team is the unit responsible for delivery at the end of the sprint, so they decide the priority. | |
| Jul 7, 2013 at 21:51 | comment | added | Loki Astari | @BryanOakley: But note there are two backlogs. The product backlog is controlled by the PO and ordered appropriately. The sprint backlog which is owned by the SM (and/or team). The stuff that goes in the sprint backlog should be from the top of the product backlog BUT not all stories can be done without other architectural stories being implemented first. So the SM (and the devs) should make sure to pick architectural priorities first when the high priority stories depend on the architectural stories. | |
| Jul 7, 2013 at 21:51 | comment | added | Loki Astari | @BryanOakley: I totally agree with you. Maybe my wording just needs refining. Maybe more the teams job (rather than SM by himself) to pick what goes into the sprint during sprint planning (PM is not a pig (just a chicken) and gets no say at this point). | |
| Jul 7, 2013 at 17:40 | comment | added | Bryan Oakley | 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. | |
| Jul 7, 2013 at 16:48 | history | migrated | from stackoverflow.com (revisions) | ||
| Jul 7, 2013 at 5:15 | vote | accept | CommunityBot | ||
| Jul 9, 2013 at 4:29 | |||||
| Jul 7, 2013 at 5:08 | comment | added | user226825 | I understand how stories are written. The PO is creating user stories to build products in my oversimplified examples. I'm not arguing about the format of stories; rather, the flapping nature of backlog managed by our PO. | |
| Jul 7, 2013 at 5:04 | comment | added | Loki Astari | @user226825: Read the definition of story. It is a description of a user performing a task not a thing. | |
| Jul 7, 2013 at 5:02 | comment | added | user226825 | I wish if they were related like a bike and a car, and it is my fault for using vehicles as an example. The PO usually stuffs completely unrelated items, say a bike and a fridge. | |
| Jul 7, 2013 at 5:00 | comment | added | Loki Astari | @user226825: Yes but in sprint one you built wheels and transmission. In Sprint 2 you built steering in sprint three you will build thrusters. Your examples are too hypothetical to really discuss further. But yes the PO gets to order the product backlog. | |
| Jul 7, 2013 at 4:57 | comment | added | user226825 | "Once you have built the bike you can go back to building the car." Right, except that for the next sprint the bike becomes a space shuttle whose stories take over the top of backlog. It's always like this - some new thing just pops up and becomes our 'top priority' even before we finish building the car or the bike. | |
| Jul 7, 2013 at 4:53 | comment | added | Loki Astari | @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. | |
| Jul 7, 2013 at 4:51 | comment | added | user226825 | I'm not saying that we want to work on the cool stories. Let me illustrate - Let's say we're building a car and PO creates 10 stories in the Product Backlog and we do 3 stories in the sprint. The next sprint, the PO says "hey guys, we actually have to make a bicycle instead and here are the 5 stories around that; they're going to the top of the backlog for the next sprint; the car is a nice-to-have but not our top priority anymore." | |
| Jul 7, 2013 at 4:49 | comment | added | Loki Astari | @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. | |
| Jul 6, 2013 at 15:27 | comment | added | user226825 | "It is the job of the "Scrum Master" to protect the developers from flippant change." Sure, but what does SM do when PO says that the new stories are indeed what the business needs and must be taken care of in the upcoming sprint? | |
| Jul 6, 2013 at 15:24 | comment | added | user226825 | In our situation, the old stories still have values and remain in our backlog. However, right before our Sprint Planning the PO comes up with new stories and they are then placed at the top of the Product Backlog. | |
| Jul 6, 2013 at 9:45 | history | answered | Loki Astari | CC BY-SA 3.0 |