Hacker News Reader

The main value of stressing about sprint goals and what's "in" a sprint and finishing it is the very specific situation of there being a bunch of people who want to feed in a large amount of work to a team (usually bugs/support requests/operational work) and it results in constant prioritization issues.

If you don't have that situation, you probably don't need to be really careful about what's in a sprint.

View on HN

Kanban lets you prioritize exactly the same way, except it doesn't have to fit into a sprint schedule. You also have to make good stories, which are independent, have a meaningful thing that gets delivered and are of a reasonable size. Then important bugs can get moved to the top of the to-do column, and get done quickly as possible without interrupting any in-progress work.

Problems with Scrum: It's nice that you did your planning poker, but all these tasks need to be ready by the end of the month regardless.

Problems with Kanban: It's nice that you set priorities to the tasks, but all of them need to be ready by the end of the month regardless.

Conclusion: If there is more work than people can realistically do, and it all needs to be done no matter what, it doesn't matter what process you use; people will be stressed and burned out.

Reply on news.ycombinator.com