3 ms·

Prioritizing what to work on is the same problem in Kanban or Scrum. This isn’t a differentiator between the two.

sgarland 3y ago
In Scrum, I have to argue during a meeting why something in the backlog is important, and if I can successfully convince others, I then have to apply an abstract, unitless measure of complexity to that task, keeping in mind that not everyone has the same skillset. Worse, if the team completes all of their tasks ahead of time, we have to revisit Step 0 to decide what to pull into the sprint, and then discuss during the retro why we underestimated the length. In Kanban, I get shit done, and when it's done, I get more shit done.
- gwynforthewyn 3y ago
  This is by one the dudes who invented story points, and is really worth a read: https://ronjeffries.com/articles/019-01ff/story-points/Index.html https://ronjeffries.com/articles/019-01ff/story-points/Index... It explains what they were aimed to solve, and acknowledges their modern day abuse. If you read Extreme Programming Explained ed 2, you see Kent Beck acknowledging them as an early experiment that they decided wasn’t useful.
- brightball 3y ago
  The only difference between Scrum and Kanban in terms of work priority is that with Kanban you prioritize the backlog and take the next thing off the top. With Scrum you prioritize the backlog and try to forecast the volume of items from the top of that backlog that you'll be able to work into the sprint based on past velocity. You're not wrong about the arbitrary estimate. Prioritization is a function of the company and/or product team. If you need to do something in the sprint that you didn't know at the start of the plan, yes there are definitely scrum teams that would try to stop you because they are too strict with their process. Don't get me wrong here, this perception is a standard antipattern that you see in scrum shops. I've only seen a scrum team once in my career that was actually effective and I'm a huge Kanban advocate because of it. https://news.ycombinator.com/item?id=17154355 https://news.ycombinator.com/item?id=17154355 But prioritization still happens at a higher level than the team itself. It has to because it defines the direction of the company. Most importantly, deciding what you're NOT working on so you can focus on what matters.

In Scrum, I have to argue during a meeting why something in the backlog is important, and if I can successfully convince others, I then have to apply an abstract, unitless measure of complexity to that task, keeping in mind that not everyone has the same skillset. Worse, if the team completes all of their tasks ahead of time, we have to revisit Step 0 to decide what to pull into the sprint, and then discuss during the retro why we underestimated the length. In Kanban, I get shit done, and when it's done, I get more shit done.

gwynforthewyn 3y ago
This is by one the dudes who invented story points, and is really worth a read: https://ronjeffries.com/articles/019-01ff/story-points/Index.html https://ronjeffries.com/articles/019-01ff/story-points/Index... It explains what they were aimed to solve, and acknowledges their modern day abuse. If you read Extreme Programming Explained ed 2, you see Kent Beck acknowledging them as an early experiment that they decided wasn’t useful.
brightball 3y ago
The only difference between Scrum and Kanban in terms of work priority is that with Kanban you prioritize the backlog and take the next thing off the top. With Scrum you prioritize the backlog and try to forecast the volume of items from the top of that backlog that you'll be able to work into the sprint based on past velocity. You're not wrong about the arbitrary estimate. Prioritization is a function of the company and/or product team. If you need to do something in the sprint that you didn't know at the start of the plan, yes there are definitely scrum teams that would try to stop you because they are too strict with their process. Don't get me wrong here, this perception is a standard antipattern that you see in scrum shops. I've only seen a scrum team once in my career that was actually effective and I'm a huge Kanban advocate because of it. https://news.ycombinator.com/item?id=17154355 https://news.ycombinator.com/item?id=17154355 But prioritization still happens at a higher level than the team itself. It has to because it defines the direction of the company. Most importantly, deciding what you're NOT working on so you can focus on what matters.