3 ms·

If the sprint commitment gets bounced in favor of stuff coming in mid-sprint, they in itself might be useful information to someone who’s interested.

• fendy3002 4y ago
  But the reality is you cannot hope for management to realize it, and for a good reason. If reprioritize a new feature can bring more revenue compared to original plan, or if a better flow is now available due to other team's completed task, or if a severe bug is discovered someday, it's just logical to reprioritize.
  • emodendroket 4y ago
    That’s not the point though. The point is to have an answer when someone asks why the original thing didn’t get done.
  • tharkun__ 4y ago
    Things changing as a complete 180 mid sprint every single sprint doesn't mean Kanban is more suited as a process. It means your company is not using any process but rather is just a chaotic "who screamed the loudest most recently". If you do Kanban right you have to have predictability through tasks of roughly equal size. If you will you can think of Kanban as Scrum where all tasks have to either be sized 2 or 3, else they don't make it into a sprint. New items get added to the end of the backlog by default and stakeholders know when they can expect their request to be done because you know your velocity and queue length. Putting every single request that comes in at the top of your Kanban backlog is orthogonal and bad.