At Pivotal, I learned that having sprints is silly. They have the concept of one week iterations instead. The PM just keeps a rolling backlog of stories and devs just pick the next one off the top. Dev's are responsible for pointing the stories and the sum of those points averaged over time (usually 2-3 weeks) become velocity.
Just keep the velocity as consistent as possible and things work out for the best. If the PM wants a story moved up the list, then they can see how much work will fit into an iteration and how it will affect schedules.
All of this is managed in their homegrown, but publicly available tool called Pivotal Tracker. You can read the website documentation for a more thorough explanation. Once I learned this methodology and started practicing it like a religion, deadlines went away and PM's could estimate due dates many weeks in advance. It was a life changing experience that I highly recommend at least giving a shot at your own workplace.
Sounds like every agile team I've ever worked on - sprint and iteration is usually interchangeable.
The problem is that Devs making estimates tends not to be accurate IME. Some stuff is easy to estimate, but adding in new & significant functionality is notoriously usually hideously mis-estimated (either high or low). So much so that the numbers basically b come meaningless and can't be relied upon because every major new thing was a lot easier/a lot harder than expected.
The reaction to this is to split the task up, but this often requires that you do a lot of pre-work-work to architect and design the work so you know how it can be broken up, and that design work needs to be estimated so you are back at square one with wildly inaccurate estimates.
If the story estimation isn't accurate, then the velocity goes haywire and this shows up in the reporting in Pivotal Tracker.
So like you said, devs learn to get better at forcing the PM's to split the stories into smaller chunks. Smaller stories are almost always easier to accurately point since it is always 2 (1 point for the story, 1 point for testing).
The numbers are not meaningless though. That is why velocity is an average of 3 weeks. A single week doesn't blow things out of the water and if it is a new project, the expectation is that we won't know where we are at all those first 3 weeks. It gives a built in ramp-up period for the project.
Agreed, the PM's role is SUPER important. For this reason, at Pivotal the PM's usually have a developer background.
Aren’t you putting all your faith in the PM in this methodology?
The way you describe it, a developer’s role is to point out stories and jointly perform the work the PM has allocated.
Instead, if those same developers understood the users, use cases and metrics and co-created the work the team does, the team would have 10 or mor engaged minds all working to make a better experience instead of the one super PM.
Teams often work this way in practice. The product owner has ultimate responsibility for choice and priority of stories, but like any competent leader, they will exercise that responsibility on the advice of their team.
If the team's programmers are "product-minded" [1], then the PO will be getting lots of input from them, and in a healthy team will be going along with most of it - the PO is in a "first among equals" kind of position. If the programmers are not like that (junior, new to the domain, just not built that way), then the PO will make the product decisions without them (but still with the support of a product designer, hopefully!).
There's an excellent leadership principle in the UK armed forces (and i'm sure elsewhere) that a leader must consult their subordinates before making a decision, but that once a decision made, subordinates must go along with it. The PM - programmer relationship around prioritization is an example of that.
It isn't black and white like that. The team always has a voice and can express it at any time. Communication is always key and that is the whole point of developers pointing stories. They could just call a story 8 points and the PM would never get it into the backlog. =)
The PM is the conduit between the business needs and the developers. The PM and the lead team dev decides the backlog. Devs just pick the next story from the queue, but of course they have input on things as well and can convey this in any of the meetings or directly with the core dev or PM.
How can this state of affairs where developers grind out CRUD features and complain about how bored they are be stable? The identifying feature of areas where automation would be profitable is human boredom, and this is something where developers are the ones bored. Why hasn't all of the repetition in CRUD stuff been dealt with by now?
CRUD has been automated a long time ago. It's trivial to create forms with 120 fields based on scaffolding and automate the DB access with an ORM. It is time intensive to actually make software that is better than the paper equivalent. The scaffold puts everything on one page so you split it up into 10. You still have to interact with other systems to autofill form fields. Implement app specific access controls (only users in the same department can see each others forms, only X can actually edit). Implement the actual workflow (ask for digital signature from superior, send email, send end result to SAP or whatever).
Saying this is saying like "why do we need architects to design houses if all of them are just four walls and a roof?" Software engineering is not that different from mechanical or civil engineering or whatever other kinds of it. However you automate any design process, you'll still need engineers to properly utilize that automation, customize, verify, maintain (oversee manufacturing or software deployment) and fix problems.
In practice, most places I've worked treats sprints much closer to how you describe your iterations than to a fixed amount of work.
Most of the time, the sprint planning just provides some ceremony around ensuring important stories are discussed and points allocated, and priorities set, and the planned sprint is pretty much a line in the backlog that suggests an aspirational goal that is likely to change. The point is rarely to hit exactly that, but for it to serve as a means of talking about what needs to be done first - whether something needs to fit into this round, or can wait for the next. It also serves as a means of talking about inter-dependencies and sequencing of changes.
I think you've been lucky in where you have worked. You read some of the other responses and it isn't the case at all. I've seen some really tragic examples.
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”.
I doubt it’s luck. In every place I’ve ever seen Agile in use, they treated 2-week sprints like you describe iterations. It was generally expected that portions of stories would roll into the following sprint and there was a high degree of trust and autonomy in letting teams organically decide if & when any stricter deadline needed to be imposed.
One week sprints are also fine, but I’ve always found everyone hates them for doubling the number of planning / backlog / etc. “process” meetings.
One month is often too infrequent for these meetings, one week is too frequent, so 2-week sprints appear from this sort of naturally. As long as you don’t conflate the timing of the sprint with the timing of work tasks (eg accept there are single work tasks that cannot be chopped up into two week incremental subtasks) this seems fine.
The problem I've seen over and over again, and others have mentioned here in this great thread, is that when you have a 2 week sprint... if a feature misses the sprint, it is another 2 weeks before anyone sees anything... so now it is a month, which can be really unfortunate.
It gets especially bad if there is a lot of fire fighting happening as well because someone might get pulled off that feature and now the time goes to infinite...
The idea is to try to prevent that type of common delay.
That’s not how I’ve seen it work anywhere. If you do 2 weeks of work and the feature is a few days away, the portion of work that continues into the following sprint is just a few days, and then you see it.
Fire fighting is just as likely to prevent completion in one sprint as the other, so there is no net change in how the effects of context switching for firefighting slow progress.
Of course, restructuring teams and work so that firefighting effects are reduced is always the goal, I’m just saying it doesn’t matter at all in terms of when the arbitrary cadence for syncing and planning are chosen.
We have tried 1, 2, and 4 week iterations. The problem with 1 week was that we didn't feel the planning and retro overhead was worthwhile for such a short amount of work time. 2 weeks was our sweet spot. 4 weeks was just too much time between larger re-orientations.
Sounds more like a sprint than an iteration since iterations are 1 week.
As I mentioned already in the thread, retros are not just about the work... it is a check in on what went good, meh, bad during the week. It can be about anything, not just work. The idea is to have one hour at the end of a week closeout team bonding where anything can get laid out on the table.
Your iterations are 1 week. An iteration could be any length of time. And retros are exactly what you said. During our retros we have talked about iteration length multiple times and tried varying ones. In our retros everything is on the table for discussion, but it sounds like that's not the case at Pivotal.
'Your' is Pivotal. I'm just talking about how they do things and what I learned there.
At Pivotal, an iteration is a week and it doesn't make any sense to make it longer than that. What would a longer than 1 week iteration really be? Are you making them longer only because you don't want as many retros?
I said:
"The idea is to have one hour at the end of a week closeout team bonding where anything can get laid out on the table."
You said:
"In our retros everything is on the table for discussion, but it sounds like that's not the case at Pivotal."
There is a disconnect somewhere cause I'm pretty sure we are saying the same thing. =)
> At Pivotal, an iteration is a week and it doesn't make any sense to make it longer than that.
It might. For example, if your team is distributed (eg development in the Pivotal office, infrastructure in the client office), you might prefer to have retros once every two weeks, rather than either drag the infrastructure people across town every week or have retros remotely.
On some projects i anchored, we had planning meetings twice a week, because planning went more slowly, relative to development, than usual, due to complexity of features, multiple stakeholders, etc. We still had retros once a week. Was our iteration one week or half a week?
The truth is that iterations don't really exist. You have planning meetings at some frequency. You have retros at some frequency. You have client liaison meetings at some frequency. You may have various other meetings at various other frequencies. Sometimes the frequencies are the same, but it doesn't mean anything.
I came across as argumentative in my first response. I didn't mean to :)
> There is a disconnect somewhere cause I'm pretty sure we are saying the same thing.
Sort of. In our retros everything actually is up for discussion. If people think 1 week iterations may work better for us, we may try them out (and we have). We got rid of daily standups because of a retro discussion (they may come back if we feel communication is lacking). The point is there are no sacred cows.
You already stated a few things that appear set in stone. 1 week iterations, pair programming, daily stand ups, and everyone at the office for the same hours every day. From my standpoint that appears very rigid, and I wonder what there is to talk about in the retro if the development process is static.
Many Pivotal teams hewed closely to the default practices, but not all. The most dogmatic is Pivotal Labs, because its job is to teach the basics. Having a rigid, predictable structure works better to start folks off.
I've seen every sacred cow at Pivotal slaughtered by Pivots and guests, when it was felt that this was the right and effective thing to do.
I just asked the same thing because I've had that experience too. I'm curious: are you usually working on things that require close collaboration between team members?
My hunch is that standups are pretty useless on teams where each developer is working on an independent change where there isn't much opportunity to get blocked by teammates aside from waiting for code reviews and the like. That's most of the teams I've worked on, and the standups inevitably turn into a verbal form of, "Hey manager, here's my status report for the day even though you already know all this because I've already said it in Slack," because you have nothing to ask of the other people on the team but you're required to say something every day.
Where I've seen standups work effectively is when an engineer has a bit of context on a problem that someone is dealing with, or an insight that might unblock someone. I've had many times I've mentioned in an (async, written in slack) standup status update, and someone's chimed in with something like "Oh, I've dealt with that before - let's pair for 10 minutes so I can walk you through some gotchas".
Another plus for me personally is that it has a focusing effect on myself as a developer - if I say I'm going to get something done in standup, I'm going to force myself to focus on that task, and not get distracted by something else unless it's really important. I can see how that's a totally personal thing though - I need to have some sort of external "deadline", even if it's self-imposed and soft, to keep me focused.
All of the above can be solved with async updates in Slack though, and that's probably actually a better medium. Having folks get in the same room seems a little pointless to me, especially when you have remote folks and timezones are an issue.
The problem I've had with async updates is that they often get ignored because everyone that could help is busy at the time, so you still need the actual standup to just remind them about it. How do you get around this?
I don't have a great solution for that, really, other than ensuring that updates are highly visible in a room where people are likely to read them and have a good culture around helping folks.
I've been in environments like the one you describe, and I think at the end of the day it's more of a cultural issue than something that can be solved using a tool.
I get around it by pinging people directly (usually I reply to my question as a thread in Slack and @-mention them, so the main channel doesn't get cluttered with my reminder) if a couple hours go by without a response. Still usually faster than waiting until the next day to ask at standup.
My hunch is that standups are pretty useless
on teams where each developer is working on
an independent change where there isn't much
opportunity to get blocked by teammates aside
from waiting for code reviews and the like
Personal anecdote, but I like to know what my teammates are working on even if we're not collaborating directly.
I could (and do) read their commits and PRs, and standups are not a replacement for that, but I think you can usually get a better idea just by chatting for a few minutes each day.
I view the cost of a daily standup as very small (they should be only a few minutes long!) so while some would call the benefits modest, I think the "time spent vs. value obtained" ratio is still very good.
For me the cost is much less about, "It's just a few minutes long" and much more about, "Having to get up from my desk and talk to people about their projects kills my flow state." It's a short meeting but it's still a meeting and has the same effect on focused thinking as a longer meeting. Losing focus is totally fine if there's benefit to it, but for standups where I neither learn nor teach anything new, it's all cost and no benefit.
I too like knowing what my teammates are working on, but I already get that from the team's Slack channel where people talk about what they're doing as they do it.
I agree about the frustration of having my flow disrupted, but my like of daily standups is related to my experience that they create an overall reduction in interruptions.
Of course, that's my experience. Others may have had different experiences and I respect that. If you formerly had 0 interruptions per day and now you have 1 interruption per day, that would be frustrating. I would also like to work where you work!
>I view the cost of a daily standup as very small (they should be only a few minutes long!) so while some would call the benefits modest, I think the "time spent vs. value obtained" ratio is still very good.
My problem with a morning standup is that it completely destroys my productivity if I come in early and really get cracking on a problem, then have to stop and task-switch. I'd much rather make it optionally asynchronous.
Yeah, I feel the same way sometimes regarding the timing. I don't think they should be in the morning. The older I get, the more of a morning person I am... that's my productive time.
I personally would rather do those meetings in the early afternoon, like before or after lunchtime.
Pretty sure there are plenty of studies that show early afternoon is our least productive time anyway.
(TBH, and I'm being completely serious here, my ideal schedule would also involve siesta time in the early afternoon)
Standups are for "weakest" devs, to break silo of "I am working on my thing don't bother me".
"weakest" devs - you know not everyone is outspoken and will communicate without issues, new young devs will be afraid to ask an experienced guy. Some experienced guys (also "weak") will be assholes to young devs for asking questions. Just getting team to talk to each other at least once a day is positive. Unless you work only with senior people who are experienced and don't have any issues talking to each other, I would still try to get people to gather for standup.
The best dev on my team is also a very reluctant communicator.
This guy is a beast at getting things done, and is a good communicator once you get him talking. Overall, a joy to work with. However, you do typically have to make the first step. He kinda stays dark without scheduled meetings.
To me the key is to keep the daily standups VERY brief. They help the "reluctant" communicators. And they don't cost the "active" communicators very much time.
I am a fairly "active" communicator myself. I'm gonna spend 15 minutes talking to my freaking team every day anyway. So a brief 10-15 morning standup is no problem at all.
Counterpoint: comment was fine and non-toxic, describing siloing as weak no matter who's doing it is an accurate and a pretty tame criticism, and ensuring that's not happening is indeed the only real point of scheduled daily stand-ups. As long as we're gonna have the term "senior"—and we do have it—I'd abso-friggin'-lutely reserve it for people who can avoid siloing without a formal, daily ritual, and a team of such folks don't need stand-ups. Don't worry about it, ozim.
> Nobody should be an asshole. Nobody should be working alone.
Ozim advocated neither being an asshole nor working alone, so is perpetuating neither. Standups have a place and it's to fight both of those problems, when some ICs on a team can't handle it on their own.
How would you express that thought, to get through to a person I replied to who wrote he has 15 years of experience and he did not see any value in standups?
Do you think he is not a senior person? Is he a bad person for pointing out his years of experience? Maybe I am bad person trying to express in BOLD that there are people with less experience, social anxiety, assholes and we have to work with all those personalities. With strong emphasis that standups are good tool for getting rid of toxic work environment and getting teams together.
I agree that the whole typical 'what did you do yesterday' is indeed lacking value.
The standups are mostly just pointing the stories that need pointing, covering any questions and picking the pairs for the days work (pivotal is 100% pair programming). The meetings can be done within 5-15 minutes at most.
I'm currently living at a yoga retreat center in the mountains of Vietnam. I can see from the practice that the first few minutes of silence is good to clear the mind. I think having standups is a similar good way to start the day with a positive attitude.
I also find value in standups, but the problem is they constrain the team to some daily meeting time. For example, I start work around 6am. A co-worker does morning kid duty and tends to start closer to 10am. There is no good way to start our days at the same time, and there really is no need.
What we have been trialing for awhile is a simple Slack checkin. Everyone reads them when their day starts, and if there are any questions or comments a Slack thread is started from the checkin message. It's worked quite well.
Pivotal solved that by requiring everyone to work the same exact hours. It is a bit military in that regard, but it works for them. You don't get a job there unless you buy into it. Their reasoning is more around their culture of pair programming.
It sounds like you have found a solution that works for your company and that is great! The way I look at it is that as long as we are shipping software around the time when we say we are going to and the quality is high and people aren't killing themselves (weekends) to make it all happen, all good. =)
First off, I'd say that a good daily standup meeting shouldn't be more than 15 minutes. If it's longer than that, you are probably getting bogged down in details that don't belong there.
Let's be generous and call the "real" cost 30 minutes of productivity... 15 minutes for the actual meeting/call, and 15 minutes of context switching cost.
That is 6% of an 8-hour workday. You can still code up to 94% of the time, not bad. And I think it has been shown many times that most developers don't really pound out code for 8 hours per day. We might work 10+ hours per day but it's not necessarily 10+ hours of coding. So I feel the cost of these daily meetings is very small.
What are the benefits?
1. For one thing, it is good to know what the rest of your team is working on and what challenges they are facing. This jogs a lot of useful conversations in my experience, where Developer A turns out to have some experience in the area in which Developer B is stuck. You may be thinking, "good teams communicate and can do this literally any time... why schedule a daily meeting for it?"
Yes. If your team is operating and communicating flawlessly, sure, standups are redundant. However, I've been at this for 22 years and this is not typically the case, and the brief daily meetings are a real upgrade.
2. These meetings help prevent "drive-by shootings." That's what I call it when management randomly stops by your desk and wants to know what you're doing and if you're stuck and wants to see your work in progress. I hate hate hate hate these. I would rather just briefly chat with leadership on a predictable basis. And when I am leadership, I would prefer not to subject my team to these "drive-by shootings." A lot of teams are already paying this cost, which I feel is much greater than the cost of a brief morning standup. Again, if your team is already communicating at a super high level, maybe you don't need standups. I feel this is not the case for a majority of teams.
3. For remote teams, these give folks a chance for some regularly scheduled face time and chitchat. We kept our morning call to < 15 minutes today and talked about Star Wars. As a remote worker myself I truly cherish this. If you have a remote team I would call video chat standups more or less a requirement.
Out of curiosity, how valuable are these three meetings in a typical week? What do you get out of each of them as a developer?
I've worked at a few places that follow more or less the same practice and I've found that the planning meeting is hugely valuable but that standups and retrospectives are a waste of time more often than not.
Remember, meetings are what you make of them. If you can't find value in them, either change the topic to make them more valuable or don't have them at all.
The retrospectives at Pivotal are actually quite fun. Usually involves optional booze and doesn't last for more than an hour. The goal is to make them about anything, not just talk about work. It is like an end of the week team building exercise. Think about it, most of us spend more time with these people in the office, then we do with own family. So, we might as well have an hour where we put down the phones and keyboards, reflect on how the week went, find things that can be improved, talk about life events or anything really. Find the positive aspects and focus on those as well as quench any negative things so that they don't carry onto the next week.
When you say, "devs just pick the next one off the top", that sounds very much like Kanban instead of Scrum. Kanban is radically different but considered "agile". When Scrum degenerates into mgmt screaming, "you missed all your deadlines - again!", Kanban is often a great source of relief, because the only deadlines that count anymore are the "real" ones. It also allows much more flexibility with shifting priorities, which stakeholders love. Absolutely worth a try when Scrum has become a tool of oppression & misery.
I wouldn't really try to put a name on it other than Pivotal Process or Pivotal Methodology... I was just googling around to see if they even name it and found these articles...
Okay well it looks like they've put even more emphasis on pair programming, which Kanban certainly doesn't require, and... I'm not gonna advocate for that part.
Pair programming all the time comes from XP. Almost no one does it, not even Kent Beck. In fact, the only place that I know of that tried "real" eXtreme Programming was the Chrysler Compensation project, which ultimately failed.
I'd be amazed that Pivotal actually does pair programming all the time, except that they are in the business of selling tools to facilitate exactly this process.
Many Pivotal teams do full time pair programming. Many don't. Pivotal Labs is pretty close to 100% because of its teaching role. Large parts of R&D practice 100% as a default with many local variations. Other parts of R&D don't practice anything resembling pairing.
All of this is presumably going to be in flux, now that the acquisition by VMware is complete.
You don't understand how agile development actually works and appear to be confused about terminology. There is no difference between a sprint and an iteration; they are two words for the same thing. A sprint is a planning cycle, not a deadline. Many other tools such as Jira or Rally work as well or better than PT. Recommend you broaden your experience.
The end of the sprint should not be a deadline, but a goal. Wasn't that kinda the point of the article?
No one ever said a story has to fit within a sprint, that's not how agile or sprints are supposed to work. Some stories take multiple sprints. You should always break down large stories into sub-tasks that do fit within sprints.
This iteration thing your describing sounds almost exactly like sprints to me, just reworded to sound like their own thing.
>Ah, the difference is that with iterations, there is never an 'end' and goals are just epics.
Jira uses epics in the same way. And I'm not sure what you mean by "there is never an 'end'" - how does that differ from sprints? Iterations and sprints are just two words for exactly the same thing.
Good question. An iteration is a marker to generate velocity.
All of the points collected in that week are summed together and the average of those points across a configurable threshold (typically 3 weeks) is the velocity. Once you have a velocity, you can start to make predictions about the future.
For example, if velocity is 10, that means 10 points worth of stories can fit into an iteration. If the PM moves another story into the iteration, the last story would be automatically pushed into the next iteration. Makes it easier to answer the question of 'when will a story be done?' as well as 'how will changing the flow of stories affect deliverables?'
Highly recommend you read the documentation, it has been formed over many years and is excellent.
Sounds like Pivotal combines elements from scrum and kanban in a way that works well for them. That's what you're supposed to do with agile -- keep adjusting the process until it's working well for your organization.
Hi, PM here. I ditched scrum long time ago with the team and setup 1 week cycles. We meet on monday, to kick off and see results at friday. We managed to keep executable development cycles, so from my part, i tend to ask for less every single weekend because that's how I get most of the results, and keep moving. In the end, it's better than seeing results every 2 weeks and some major results in a month or so. I preffer to move quickly, and iterate those "mini-sprints" in case one went wrong.
It strongly depends on the maturity of the team. All the comments in this thread are assuming the point of view of the heroic developer and his tribulations. Managers know that some devs will sit on their hands and do shoddy work without constant prodding. A good process has the appropriate amount of incentives to move quickly and checkpoints for quality and accuracy. The more mature your team, the lighter these checkpoints can be. I've found that a lot of teams will essentially graduate from sprint-based Scrum to Kanban once they've acclimated and gained some trust. Same with estimates. They may be necessary at first, but eventually become less valuable.
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.
I don't think this in an entirely accurate history of CI.
Continuous integration originally meant that there was a single physical developer workstation that was considered canonical, and to get your work into source control, you would export a patch, walk over to that machine, sit down, merge your patch, run the tests, do any small changes you needed to get the tests to pass, then commit. If you couldn't get the patch working quickly, you would revert, and go back to your own machine and keep working on it.
Changes were serialized by the fact that only one pair could be sitting at the CI machine. Changes would only go into source control once the tests passed. Master was always deployable.
I once used a slightly more comfortable version of this process where you did the merge and commit at your own workstation, but there was a physical token that had to be taken before doing that, so that merges were still serialized. That worked pretty well!
The transition to the modern approach of just yeeting your changes into master and waiting for CI to go red after the fact constitutes a decay of this original practice. I don't think it's a deliberate evolution.
I take the view that the build turning red in CI should be a show-stopping surprise. But given the sheer volume of automation that occurs now I've seen that standard slowly abandoned from sheer signal fatigue. It's hard to notice a red box when you have hundreds of boxes on-screen and there are a sprinkle of reds.
I'm not sure if I like that state of affairs. It feels like eroding goals or a capability trap.
To be fair, if you are doing TDD, then you can't drop the testing ;-) But, yep. No matter how good your process is, you can't do well with it if you don't follow it.
Edit: a particularly poorly placed lack of negative.
Just keep the velocity as consistent as possible and things work out for the best. If the PM wants a story moved up the list, then they can see how much work will fit into an iteration and how it will affect schedules.
All of this is managed in their homegrown, but publicly available tool called Pivotal Tracker. You can read the website documentation for a more thorough explanation. Once I learned this methodology and started practicing it like a religion, deadlines went away and PM's could estimate due dates many weeks in advance. It was a life changing experience that I highly recommend at least giving a shot at your own workplace.