We’re rewarding the question askers & reputations are being recalculated! Read more.

Hot answers tagged

24

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, ...


14

It is worrying that you have no why part to your user stories. This is an important element of the user story format as it allows us to evaluate the stories and to prioritise them. It appears that you are writing technical requirements but partially using the user story format. I also notice that you focus the stories on the admin, when I suspect the value ...


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

the backlog is populated by the project manager Scrum, as its defined, doesn't have any role called "project manager". There are only three roles - Product Owner, Scrum Master, and Development Team. The Product Owner is responsible for maintaining the Product Backlog. and can contain entries as abstract as he wants, with various degrees of importance ...


9

You are seeing the real velocity. Stories that aren't done don't count. If people keep working on new stories while old stories aren't moved to done yet, that means your team isn't working like a team and some level of process improvement is needed. Remember that velocity is about delivering value, not code. If it isn't ready to go into production, then it ...


8

You can do whatever you need to do, however removing stories is not advisable unless they are either wrong, duplicates or obsolete. The reason is that it takes time to write a story, and for you to read it and prioritize it. Having a story you think is very low (or no-) priority at the bottom of the pile still has a value because it theoretically prevents ...


8

The Product Owner is the absolute owner of the Product Backlog. As such, he/she has the last word on what goes in, stays in, or gets out of it. I wouldn't recommend to keep stories in the backlog "just in case." True, there is a cost associated with creating a story, but each item in the backlog will have to be maintained, reviewed, reprioritized, etc. and ...


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 ...


8

US3 and US4 seem to be the same thing to me. If you need to display the last 5 messages, then that means saving them somewhere, so US3 should somehow deal with that. If US3 does, then US4 is redundant and not needed anymore. But why do you think you need a database? As the PO you should not care about and/or decide on technical implementation details on ...


7

In traditional Scrum, all of these roles are considered part of the same scrum team. Release backlog items get moved into the sprint backlog when committed to by the entire team (no matter what function the individual team members have) and then tasked out (again, by the entire team). The reason scrum doesn't usually separate out the functional areas of ...


7

Product Owner is required to develop a release roadmap Contrary to popular belief Scrum does not mean seat-of-the-pants management with no advance planning. The Product Owner is required to develop a release roadmap. However, there are two key requirements for a release roadmap in Scrum: The timeline in the release roadmap should be based on actual ...


7

There is no "right" way to conduct your backlog refinement meetings. In fact, you can change it up to get what you need at the time out of it. My goal in backlog refinement is to set the team up to have a successful Sprint Planning. This may involve story splitting, priority discussions, or simple Q&A's. However, I often find that until the team tries to ...


7

You cannot totally eliminate dependencies. Some story will depend on another, some feature will need another feature to be built first, some new feature will be desired only after you see and interact with some already built feature, etc. That's just the nature of things. So the "Independent" in INVEST isn't about eliminating dependencies, it is about ...


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 ...


5

Moving to Scrum is hard as it is not as simple as having a team, the hard part is to get the team members to work together as a single unit (a team) and break the old habits of working in isolation. Much easier said than actually done. This is the main reason we have short sprints and a retrospective, thus allowing the team to inspect on how they work ...


5

Usually, it is not a good idea to frequently check the whole backlog with the whole team. The last 2/3 part of the backlog is going to change in the future and checking these items just waste the time of the team and generate unnecessary discussions about future issues which may not be implemented at all. The recommended approach is that the Product Owner ...


5

The backlog consists of PBIs like Epics and User Stories. I really like using User Stories. That's why I'll stick on the term in the following. But be aware that other representations might be more useable sometimes (as @Daniel pointed out in his comment). A few User Stories can be finished in a sprint. User Stories are broke up in tasks during sprint ...


5

Two main options here: Give the PO help Give the PO better tooling The Product Backlog is: an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. For a product of significant complexity, the backlog will grow to be non-trivially large. The Scrum Guide puts ...


5

There are a number of issues with this approach: Multi-tasking reduces efficiency. Every time they have to context switch between projects they will lose effectiveness. Scrum is based on the idea of a known team capacity which is used to calculate the velocity. If team members change or are doing work for other teams then the velocity can no longer be ...


5

TL;DR: I agree with you that, once you've got a grip on your backlog, that grooming is wasteful. Spending time breaking down requests that will never be implemented is waste and violates the spirit of "Maximizing the work not done." Delay breaking things down until the last practical moment (but no longer!) and you'll need to do very little grooming. ...


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

I think what you're calling out is that you have a distribution of skills on the team that 66% of the team can do front-end work and 33% can do backend work. However, the work needs something like a 60/40 skills distribution. So, what you are seeing is that there is a potential for an increase in velocity if the skills of the team matched the work a little ...


5

According to the Scrum Guide, the Sprint Planning event is when the Sprint Backlog and Sprint Goal are created and the entire Scrum Team (the Product Owner, Development Team, and Scrum Master) collaborate to produce the plan for the Sprint. Going into the Sprint Planning, the Product Owner should have an ordered Product Backlog. The items at the top of the ...


4

If I understand correctly, you are a sub-contractor to another company which is delivering a product to the customer. The customer wants to be able to run through whatever scenarios they want to dynamically in order to get the best balance of cost/scope/time. Silos are for grain and not project teams. It is better to have a discussion with all parties ...


4

Stories to be worked on in the upcoming sprint should be estimated much more rigorously than stories scheduled for many months' time. Some people call this "Rolling Wave" planning. This is how I've estimated the whole backlog in the past: Product Owner identifies stories and prioritises them. Before a project starts, the PO and 1 or 2 technical guys ...


4

Generally speaking, the PO can choose to add, remove or re-prioritise stories in the product backlog as they see fit. That said, it shouldn't just be gut feel. A good PO will be talking to stakeholders, looking at usage stats, user research etc to decide which stories are not valuable enough to deliver. They should also make sure that when stories are ...


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

Agile and Scrum are based on collaboration and teamwork If it is "non project but daily activity" Scrum is not a suitable process for that. You should consider using Kanban. However, looks like you all have decided to use Scrum. So, I will answer the rest of your questions based on Scrum. Who should propose the structure of the product backlog tomorrow (...


4

The answer is, Yes, No, It Depends, in true agile fashion. :) So I've been lucky or unlucky as the case may be and have never worked in a company with the Business Analyst role. So I can't comment on Zsolt's answer. What I do know is that in the agile community we are seeing more and more the concept of the Product Owner Team. And the concept of what I ...


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