18

In my team, if the backlog was exhausted, we always had the following to fall back on: The team can invest time and create a prioritized backlog of technical / architectural debt in your systems Work on technical debt items created using point 1 (above). Improve the automated continuous integration and continuous process. In the world of infrastructure as ...


17

The phrase "backlog grooming" was officially replaced with "backlog refinement" in the Scrum Guide back in 2013. The change was largely done for: Clarity of semantics. Arguably, the word refinement expresses the idea of continuous improvement a little better than grooming. The latter denotes removing defects or straightening out. ...


7

The Product is the thing that you are building, or the service that you offer, or the need that you want to satisfy, or the vision that you have. The Product is first and foremost an idea "to do something". Only then you can you make it happen. And only then you can decide how you will make it happen. Like putting together a Scrum team, for example. You ...


6

TL;DR The original question was tagged Scrum, so my answer will focus on how Scrum expects routine and non-routine changes to be managed. In brief, Scrum embraces change, but encourages the Product Owner to plan refinements for future iterations whenever possible. By treating refinements as new work, the framework encourages ongoing collaboration between the ...


6

The only people who an accurately estimate is the people doing the work. The product owner doesn't generally code and even when they do, their job is to ask for the team to do as much as possible. The team's job is to set their limit and say no. I work with enterprise organizations and help them with longer term forecasting. The first thing is to move away ...


5

Quite simply, start the Sprint with what you have. However, your Product Owner (and the business) must learn the lesson that the pipeline of work is never finished. Run an ad-hoc retrospective to discuss how you ended up in a situation woth redundant cycle times. Are stories not play ready? Has the backlog been exhausted? Are no further requirements ...


4

TL;DR Your question is phrased in a way that may lead to good answers that aren't quite on target for your specific use case. You say: [A]t the ending of a project there aren't enough story points to fill a 2 weeks sprint based on the velocity of the team. So, your question is really about how to handle the planning and Sprint length for the terminal ...


4

TLDR: It's the Product Owner (PO)'s responsibility to communicate the needs for the product to the Development Team in a format that they can use. I'll address your provided Pros for spreadsheets: All the specifications are in one place and not scattered along multiple stories. It's simple enough to make a filter in JIRA that will give you a report of ...


4

User Stories are an Agile Practice, Independent of Kanban "User stories" are an agile practice. They are not intrinsically part of Kanban. While many practitioners do use user stories as cards or work items in a Kanban system, this is not a requirement. User stories are common in Kanban because they are often easier and faster to estimate, not because the ...


4

There is a single sprint goal, to prioritize the sprint backlog. The team goes about what the do and when, but they need guidance. The goal is not from the user's perspective, the goal is about what the PO wants to achieve with this sprint. That might be something from the user perspective. It might not. Having sprint goals in advance is counterproductive. ...


3

Affinity estimation is a fast estimation technique usually used for release planning. You have a product backlog full of items (or a list of the most important items) and you want to get an airplane view of how many sprints the team will need to build them all. Knowing the team's velocity and sprint length, the goal is to estimate the total number of story ...


3

Barnaby Golden's answer points to the trust associated with a product, which is very interesting and goes hand-in-hand with what Tom Graves writes in Product, service and trust: A product represents the promise of future delivery of (self)-service, via use of that product. (...) When we obtain a product, we trust that that product will deliver ...


3

I like to think of a product as having a distinct set of end users who derive value from its use. end users -> People that derive final value from the product, not people that will use the thing to make another thing (i.e. it is not a component) distinct set -> Identifyable group of people get value from it, not 'the company' or some other ambiguous entity ...


3

TL;DR Spreadsheets are great for capturing data. User stories and kanban boards are great for visualizing work or providing conversation placeholders. They can exist together. The real issue is that both can be misused. Neither spreadsheets nor index cards are "features" or "collaboration," so don't treat them that way. Instead, treat them as process tools ...


3

No, individuals doing the work decide on deadlines for the individual items in the backlog, but the product owner ultimately decides what trade-offs are needed in order to meet the deadlines required for the project. For example, if the product owner finds that launching the product in two months is absolutely needed because they want to get ahead of the ...


3

Just like your short-term planning, the team is asked to make any long-term estimates as well. If you are using story points, they can account for unknowns and risks as well as effort, so the team should be able to make long-term estimates without all of the details.


2

When I first got my CSM, the course instructor specifically said that grooming was being replaced with refinement because of the child exploitation angle. I was indifferent but understood the reason for the change. For the last two years I have been working on application development projects for the Child Welfare department of my state. Grooming is ...


2

The Product Owner doesn't need to care about Tasks. You should not be creating them. You should not be looking at them. You should not care about them. You create and prioritize the Stories. The Team then creates Tasks and Sub-Tasks. The Team must update Stories when they finish working on them. There is no such thing as a 'half-finished Story'. A Story ...


2

Short answer is: yes. Backlogs are assumed to be emergent and are expected to change and be re-prioritized often.


2

TL;DR This is a good question because it exposes a common misunderstanding about Scrum theory and the value of a Sprint Goal. To illustrate your use case, though, you'd need to craft a Product Backlog from which the Scrum Team can extract backlog items that fit a central coherence. A Product Backlog that doesn't lend itself to unified Development Team ...


1

I think that nvoigt's answer is solid. I will add a few things. I see the Sprint Goal as a way for the Development Team to not need constant interaction with the Product Owner. Consider that the Sprint Goal is created during Sprint Planning as a collaboration between the Development Team and the Product Owner and helps to guide the selection of the Product ...


1

To determine which approach to use you need to dig into the implemented product architecture (not by yourself but with the team) and try to map its relevance with product's roadmap. In case you understand that architecture and technologies used for the implementation are still relevant for the further product growth: should I create my release around the ...


1

We allocate 10% as a buffer time to accommodate any urgent requests or change requests that come after the start of the sprint. Obviously it would mean re estimation and realignment of priorities. Anything more than 10% we move out other tasks with similar estimates. I know it defeats the purpose of having the sprint if you resuffle the tasks midway, but ...


1

My approach would be to send the list first and get the ranking (1 to 10) order, sit and order the requirement based on the ranking and call for a meeting with all participants, discuss and go for a ranking negotiation that enhances the understanding of what customers really want.


1

I suggest using the MoSCoW prioritization; e.g. ask them these questions for each feature: Would we have problems if this feature doesn't exist in the product? (y/n) Yes: Can we have a workaround for the problem? (y/n) No: How much relative value does it add? (1 to 10) For a single answer, YY is a must-have, YN is a should-have, and N is a could-have. For ...


1

From my experience, I recommend the Buy a Feature game. This works best if you can get all the stakeholders in the same room, so that your stakeholders have a chance to discuss their opinions. Putting a virtual "price" on features helps you to adjust the prioritization to the relative effort that it takes to implement a certain feature.


1

One way would be to set up a quick survey - there are sites that let you do this for next to nothing. Rank each feature between 1 (must have) to 5 (hardly necessary). Or else "Yes, Maybe and No" Else you could send each a spreadsheet and use a clever macro to merge the results. I think you'd get more accurate results if you ask them to choose their top 5 ...


1

TL;DR Your UAT process is currently external to your development team, and your delivery and deployment are tightly coupled. Without changing your underlying process or business assumptions, there is no way to make what you’re currently doing “agile.” However, you can: select a more approrpiate agile framework, improve your agile practices, redesign your ...


1

Great question. It sounds like your backlog has a bottleneck at the UAT state of development. Scrum.org has addressed the bottleneck issue by infusing Kanban practices into Scrum to provide hyper-transparency into scenarios like the one you've described. Having an ever-growing Sprint Backlog is an artifact of this kind of bottleneck, resulting in a sprint ...


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