Estimation Question

If code is being merged once per month, the work in progress is enormous, and it will indeed likely prove to be unmanageable. Supposedly "pushing" this WIP to the next release may not help, since even then it might not be Done.

The right thing to do with undone work is to re-estimate it on the Product Backlog, so it might then be planned into some future Sprint. But the real problem you've got is the technical debt caused by your late merging model. Frankly, the work should be continually integrated and tested in main, and kept in an immediately usable state. ​​​​What you've described is crippling the "DevOps" you aspire to, irrespective of the tools you might be using.

It's important to note that what you describe is not "DevOps". Practices like what you describe do not promote a collaborative environment between the people developing, testing, and operating the system nor do they shorten feedback loops. However, solving these problems are a significant cultural shift for an organization.

That said, there is a potential solution that is consistent with both the Scrum framework and your current way of working. It's not necessarily the best solution, but it could lay the foundation for further improvements.

If your release branch gets locked once per month, could you start with a Sprint cadence that aligns with this branch being locked at the very end of a Sprint?

If you create this branch right before, for example, Sprint Review, you would have a very clear timebox for planning at Sprint Planning. If you have a clear Definition of Done and an understanding of how much work the team gets to Done (such as velocity or throughput), you can use that as an input to Sprint Planning.

You can be appropriately conservative with your planning, as well. For example, if you craft a Sprint Goal, ensure that the Product Backlog Items that are believed to be necessary to achieve that Sprint Goal consume 70-80% of your capacity.

I would caution against breaking up work into Dev and QA effort. And if these silos exist in the team now - that is, you have people who do "Dev work" and people who do "QA work" - work on tearing down those silos. It's good to have people who specialize in quality assurance and testing on a team, but carrying out quality assurance and testing activities should not be limited to those people.

Ultimately, though, I'd want to better understand and fix your release cadence to be able to not have fixed monthly locks on release branches and find ways to speed up deployments and reduce feedback loops.

I'd like to know more about the situation.

But given what you've described, I suggest:

1. With regard to the people who control that release branch and have authority to lock the code, could your team persuade them to release more frequently? Perhaps weekly or daily? Doing so would provide more frequent opportunity to merge your work into the branch and reduce the pressure of getting a large batch of work into the once-per-month release.

If the team feels pressure, that's because they know (1) if they don't get code into this month's release, they have to (2) wait a whole month for next release.

Think of a subway train or a streetcar. Imagine there is only one train during rush hour in the morning — there would be tremendous pressure to be on the platform and not miss the train. To alleviate that pressure, do we make the train longer and take more passengers?

No…we run the train more frequently. This reduces congestion, reduces risk, and provides everyone with more flexibility.

2. I would avoid creating separate estimates for Dev and QA. In fact, I'd recommend against adding any process that further segregates those activities. Instead, perhaps the team can reflect on how to reduce the amount of work-in-progress and focus on getting a smaller batch of things all the way to Done.