25

Backlog Ownership The Product Owner owns the Product Backlog, and prioritizes it on behalf of the stakeholders. The Sprint Backlog is the property of the Team, and they are the sole arbiters of its contents. Contents of the Sprint Backlog The Sprint Backlog contains user stories popped off the top of the Product Backlog during Sprint Planning. However, ...


16

Can I add that to the sprint backlog as a new task ? Yes, you can add stories to a running sprint, if the team agrees to it. It's not a good practice though as it reduces the usefulness and predictive ability of the methodology. Some times the task's effort changes like earlier it was an 18 hr job now it's a 32 hr job This is relatively unimportant: ...


13

Business Analyst works with the Product Owner and provides him with valuable insights on the value and importance of the user stories, but the PO is still the person who sets the priority of the backlog. The same applies to the the Team's involvement. Team members provide usable information on the technical level to the PO and the PO should be able ...


9

TL; DR It really sounds like the Scrum Master and the Product Owner have both bought into the velocity and utilization trap. Break the cycle. Dissecting the Product Owner Role The PO wants to know how many hours programmer X has available during each sprint and exactly what he will do with them. Not his business in a Scrum shop. He is part of the Scrum ...


9

In a truly agile environment, does the PO go to the level of saying things like, "OK, we have 40 person hours of work for Arthur and 32 person hours of work for Candace, and since they're each supposed to be half-time on this project, they should finish that work by the end of the next sprint." ?? Well, in a Scrum environment, or in any other ...


9

TL;DR Don't plan or start work that won't fit into the Sprint. Decompose any remaining work further until it fits within the current Sprint, or let the team figure out what backlog items to descope for the remainder of the Sprint while still meeting the Sprint Goal. Then reallocate any excess slack to process improvement. Any work that remains incomplete ...


8

The direct answer is that the Product Owner prioritizes the backlog. It is, of course a little more nuanced than that. In an ideal world, the PO would just sort the backlog items by effort and value to create their priority - and that's usually what happens at first. However, the team is going to provide a lot of input about how the order selected affects ...


7

Although I cannot fault CodeGnome's answer above, I feel like the question has not been fully answered and we circle back once again to the flexibility of the names Agile, Scrum, Kanban etc. Maxim, you have several component parts to your problem which; all of which we face in our department. Multiple Project Requirements (Backlog) Project Backlogs ...


7

TL;DR No, because what you describe is not strictly Scrum - you should fix the process instead of inventing a workaround. The PO can change the product backlog, but not the sprint backlog. If the team does not agree with the required change, or cannot implement it without endangering the sprint, PO may cancel the sprint (and incur all associated costs), or ...


7

Product Owner and the Development Team collaborate The Scrum Guide is very clear on these aspects: Product Owner and the Development Team collaborate on Backlog refinement: Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the ...


6

TL;DR There's no "one true way" to organize a Sprint Backlog. A lot depends on the granularity of the stories, the idempotence of each story, and the overarching Sprint Goal. However, I would strongly recommend that Sprint Backlog prioritization be a continual focus within each Sprint Retrospective, so that the team can inspect-and-adapt that process until ...


6

TL;DR Does the Agile community have recommended processes for a single Scrum Team managing tasks coming in from multiple backlogs? Sure: don't do it. Multiple teams can work from a single Product Backlog, but never the other way around. A single team working from multiple Product Backlogs isn't Scrum, isn't agile, and is extremely unlikely to work at ...


6

I assume the surveys will yield a score each macro area, say like from 1 to 9, 9 being very high interest. I'd attach an ordinal scale to your t-shirt size estimates, 1 through 5. To make things relative, I'd take the user score for each macro area and divide it by the total user scores and do the same with the size estimates. Then I would simply divide ...


6

As you say, not every team member will finish the planned work at the same time. But as long as you don't overload the sprint then there is a good chance they will all have finished by the end of the sprint. The question is, what does a team member do if they finish early? Some possible suggestions: Help other team members that are still working on sprint ...


5

TL;DR My research is covering on how we could have 1 SCRUM board for 1 Team that works on multiple projects simultaneously. SCRUM methodology is not just for working on 1 project, it tells us what kind of work we have to complete and how we are going to complete it (and in what timespan). [Sic transit throughout.] Working on multiple projects ...


5

A better solution would be setting up a webcam he can connect to at any time - then he can see what is going on and it doesn't make any extra work for anyone in the team. I can't see it doing any harm and it will keep him up to date (to an extent) whenever he feels the need.


5

Although the answer provide by @CodeGnome is technically correct, however JIRA Agile User's Guide mentions the following: It may take several sprints to complete an epic JIRA seems to use epics for categorizing the product backlog based on features or themes, which is why an epic may span multiple sprints. Epics are then decomposed into smaller ...


5

TL;DR No. Product and Sprint Backlogs should be organized in priority order. Themes, Not Epics To understand the difference between epics and user stories, there's no better source than Mike Cohn's blog entry on the topic. An epic is a large user story that needs to be decomposed before it is pulled into a sprint, while a theme is a collection of related ...


5

Scope Should Never Change Within a Sprint We are currently working on a project were we receive a lot of change requests, and the client insists that we should deliver the changes in the current sprint itself! This is a sign that You Are Doing Scrum Wrong™. While there are certainly edge cases where stories can be added or removed from the Sprint, ...


5

TL;DR If you want to score things, you need to convert to a numerical or ordinal value to perform a comparison. However, part of the challenge is that you are using the wrong tool to compare features in multiple dimensions. Tee shirt sizing is a good relative comparison for level of effort, but isn't useful for comparing multiple criteria against each other ...


5

The Scrum Master is not part of the Development Team. Your assessment is correct - the term "Scrum Team" refers to the Scrum Master, Product Owner, and Development Team. The Development Team includes all of the people who are doing the work to transform Product Backlog Items into a potentially releasable Increment at least at the end of a Sprint. If the ...


5

Sprint Backlog Tasks Aren't Inherently User Stories You're conflating user stories and tasks. Product Backlog Items often start as user stories on the Product Backlog, but Scrum doesn't mandate the user story format. Those Product Backlog Items get imported to the Sprint Backlog during Sprint Planning. Stories are often refined further at that point, and ...


4

Scrum does not mandate estimation of any kind, actually. It doesn't even mandate user stories to be honest. Jeff Sutherland and Ken Schwaber put together a quick guide with the essentials of Scrum here http://www.scrumguides.org/ - it's worth a read. That said, it is very hard for a team to consistently deliver on their sprint commitments AND be taking ...


4

TL;DR There's nothing fundamentally wrong with this approach. One assumes universal competence with a digital camera, so it's up to the team to decide who should be on camera duty. There are trade-offs with any type of Sprint Backlog artifact. Decide which is best for the Scrum Team, and then figure out the best way to share that artifact with other ...


4

TL;DR Ideally, a Sprint should provide a coherent increment of functionality. In practice, teams may pull in stories that aren't aligned with the singular Sprint Goal, but this requires advanced Scrum-fu. Even when pulling in additional stories, some strategies are more successful than others, and great care must be taken not to violate core Scrum ...


4

User stories should have enough basic information like who (type of user) wants what functionality and why is the functionality needed. Also, what is his or her success critrion for the story. Details should be avoided in the user story as they will be discussed as part of sprint planning meeting. it is very tough to strike the right balance but an ...


4

If you stick to a strict interpretation of Scrum, 1 story board = 1 team = 1 project. Could you use multiple story boards? Sure, but purists would probably argue you're not doing Scrum anymore. Are you doing Agile-Scrum? Yes, possibly... If the solution you choose (one or many story boards) is desired by the team(s) and improves their ability to deliver ...


4

You need a full-time dedicated Product Owner for the Scrum teams In one of my previous assignments, as the Scrum Master, I worked with a group of Product Managers similar to what you describe. Also, the Product Managers had many other priorities and so getting requirements clarifications or Customer Acceptance Testing (CAT) from them in a timely manner was ...


4

This is responsobility of Product Owner and Development Team. Product Owner: In article Roles in Disciplined Agile Delivery is written following: Product Owner. In a system with hundreds or thousands of requirements it is often difficult to get answers to questions regarding the requirements. The product owner is the one individual on the team who ...


4

Budget time for such production bug triage work This is not very unusual. Most software development teams have to be prepared to fix production bugs on priority, if any are reported. It is also quite normal that bug reports need to be triaged first even though some of them may turn out to be not bugs at all. However, your team seems to have more of them ...


Only top voted, non community-wiki answers of a minimum length are eligible