Teams which constantly re-prioritise items which some fake product manager came up with a few months ago is not agile.
I don't disagree with this. However,
>True agile teams never need to do backlog grooming. If a team has a backlog which is so big that it needs grooming, then they are not agile. An agile team build something, releases it to its users, and afterwards react to the immediate feedback/next important request.
This is like saying the first test should always fail because the tested code doesn't exist. While that's a good start, it usually takes a few sprints to release anything useful; especially if you have any hardware involved. Therefore, having a number of stories in a backlog really helps, especially if you do have to re-prioritize because hardware is delayed, etc.
Our team uses backlog grooming to point tasks and assign them "definitions of done". This is done to solve two problems: getting everyone on the same page as far as how the task will be done, which also speeds up diff reviews, and to determine if the task should be split up into smaller tasks.
When would you perform these tasks?
> Teams which constantly re-prioritise items which some fake product manager came up with a few months ago is not agile.
This is not at all what we do with this meeting.
I agree 100% that it's not Agile.