In my experience, there are a few reasons why you would choose sprints over a continuous backlog like this. Originally, these kinds of agile processes did not

In my experience, there are a few reasons why you would choose sprints over a continuous backlog like this. Originally, these kinds of agile processes did not use continuous deployment. Often you used trunk based development (TBD) where you merged your work directly into trunk/master several times a day. Continuous Integration servers were invented because this style of CI often broke the build. You wanted the test suite to run after you pushed so that other developers would be alerted to a broken build before they pulled. Of course even better to check before you merge, but the source management systems of the day often weren't capable of doing that easily. Sometimes even making a branch was hard work. The end result of this kind of system was that master was not always deployable. You needed a point in time where the system was deployable. That's the end of the sprint. Although it's a very unusual way of doing development these days, prioritising true CI over CD has definite advantages in some environments. In the same spirit, the longer you keep code out of trunk/master, the more risk you have and the more difficult it is for people to do refactoring. If you make large changes over a whole week, then you end up with difficult integrations. Even if you aren't doing true CI (i.e. actually integrating your code with everyone else's on a continuous basis), it's important to limit the amount of time your branch is held out of master. If you have a 2 week sprint and you have 1 week stories, you will almost certainly fail every single sprint (been there, done that ;-) ). The only way for a sprint to succeed is if the vast majority of stories are small enough that you are unlikely to start it without finishing it. The funny thing about having small stories (around 10% of the size of your sprint) is that if you are doing them, then having a sprint end is inconsequential. You may drop a story or two from your board if things don't go as planned, but you will almost never start something and not finish it (especially if you prioritise stories by risk). So the main reason for preferring sprintless backlogs is because keeping the story size small is difficult. In order to keep all your story sizes small, you have to be doing some things very, very well. First, you need to be doing your analysis very well. If you don't know exactly what you are building before you start, you will have wide variability in the amount of time it takes. It will also be very difficult to break problems apart because you aren't entirely sure where the good break points are. Second, your code needs to be very, very clean. You need to be refactoring literally constantly. The code needs to be simple in order to break your problem up easily. This requires a lot of iterations of design in all of your code as the code grows. All of this actually feeds back to the preference for CI over CD. It's not a system that a lot of teams will prefer to use, but it has definite advantages. My experience has been that the potential is quite a bit better, especially over time. You need a team that is completely on board, though. It is especially difficult for PMs who usually don't want to think about problems in as much detail as is necessary for this system to succeed. However, I would encourage developers to keep an open mind because when it works, it works amazingly well.