Hot answers tagged

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


15

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


12

The main ideas with Kanban is to visualize your work and to limit work in progress. This allows you to maximize flow while at the same time see where you have bottlenecks. If you started work on something that now needs to stop for whatever reason, you need to remove it from your work in progress. What you do with it depends on what exactly you want to ...


10

the backlog is populated by the project manager Scrum, as it's defined, doesn't have a 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 ...


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


9

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


8

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


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

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

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


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


5

TL;DR Anyone with sufficient permissions in JIRA can move the stories during Sprint Planning. It doesn't really matter who actually moves the stories. What matters is that the stories are pulled by the Development Team, and never pushed. Responsibility for Moving Backlog Items The Scrum Guide clearly states that the Development Team is responsible for ...


5

Increase Resources or Set Expectations Lower I'm not sure what your actual question is, because from a project management perspective you have only three core sliders (also known as the "iron triangle") that you can adjust: Cost Schedule Scope What you seem to be talking about is scope management as the adjustable slider, which you can tune to accommodate ...


5

Although I support what Todd wrote, there is more under the surface than above. So my answer based on my experience as a program director is as followe. The "golden" triangle is a myth (yes its there on an economic/math basis) but we are talking about social systems here.So as Todd pointed out you will have no chance to succeed on the given parameters. ...


4

Work towards a self-organizing and cross-functional team Looks like your first question is how to carve out sprints from the product backlog. The Scrum team should work towards delivering a potentially releasable Increment of “Done” product at the end of each Sprint. You may or may not actually deploy at the end of each sprint. In order to accomplish this, ...


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


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