Maybe. But the point is that there isn't really that kind of sharp delineation, but a spectrum where you really can't assume that people talking about "sprints" means a fixed amount of work.
The process you describe fits precisely within the Scrum framework; a key point of the retrospective in Scrum is not just to understand what has been delivered but what caused deviation from the estimate at the start and why. The assumption throughout is that the forecast from planning is just a forecast and that what will be delivered will pretty much never be exactly that.
Maybe there are other things you do that does not match Scrum, but the above fits Scrum better than attempting to turn it into static/fixed releases - after all the entire point of pretty much all iterative development processes is the acknowledgement that we do not know how to precisely estimate software development with sufficient accuracy to create precise estimates for specific sets of tasks.
If you want to put a name on it, Pivotal is just a type of scrum. They have their own sauce. I personally called it the Pivotal Process... but I'm probably the only one.
At Pivotal, the forecast of what will be delivered changes all the time and it is tracked in a single tool that everyone can look at and keep up to date with (along with a few short meetings to keep everyone on the same page).
> They have their own sauce. I personally called it the Pivotal Process
What Pivotal does is fairly vanilla Extreme Programming. Indeed, the vanillaness of it is something of a selling point. In the London office, we would start projects by giving client PMs and programmers a copy of Extreme Programming Explained and telling them that was what we were going to do. It's easier to coax them into following a process if it's a documented industry-standard one rather than some special sauce.
Pivotal does have a few extra bells and whistles that fill in spaces around the XP core - "discovery and framing" [1] and "inception" [2] being two that spring to mind. And as you say, there is less emphasis on iterations as a unit of work - the planning meeting is weekly, but it feeds a continuous flow of development and delivery. But the daily pattern of work should be familiar to anyone who knows XP.
I was told that the main thing that makes Scrum Scrum is that the team chooses the sprint goal, from amongst the tickets at the top of the backlog, and the team commits to hitting that goal.
In my experience more typical is that the PM chooses a set of tickets and asks the team whether they can commit to them.
According to the constraint above, neither that, nor the “pick from the backlog” process you’re describing would qualify as “Scrum”.
The process you describe fits precisely within the Scrum framework; a key point of the retrospective in Scrum is not just to understand what has been delivered but what caused deviation from the estimate at the start and why. The assumption throughout is that the forecast from planning is just a forecast and that what will be delivered will pretty much never be exactly that.
Maybe there are other things you do that does not match Scrum, but the above fits Scrum better than attempting to turn it into static/fixed releases - after all the entire point of pretty much all iterative development processes is the acknowledgement that we do not know how to precisely estimate software development with sufficient accuracy to create precise estimates for specific sets of tasks.