I've been doing research on CI (continuous integration) and I can't find any info on the changes CI would introduce to ticket sizing.CI states developers should merge to the mainline every day (or even multiple times a day), but if that is the case doesn't that mean when sizing tickets those tickets would have to be broken down into even smaller tickets that would only take a day or less to complete or am I just integrating fragments of code that pass unit test but are not the complete ticket?example: say I have a ticket that my team would normally size a 3 which would equate to 5 working days, under CI rules would a developer be integrating the commits (that pass unit testing) he or she did for that day into the mainline (keeping in mind the ticket is still not complete) or is that ticket to large for CI and in turn the ticket would need to be broken down into smaller tickets where each one of those new smaller tickets would need to be done in a day or less?
continuous integration impact on ticket sizing
agile;scrum;continuous integration
under CI rules would a developer be integrating the commits (that pass unit testing) he or she did for that day into the mainlineThe features you are developing should be developed in pieces, so that you can continuously verify they pass all your builds/tests. Hopefully your CI processes are setup to run on your branch as well as your master.If you are working on a repository which is quickly moving (lots of merges to master), when working on a feature branch you should be often pulling in and merging with master.Then, when you make your commits you are working very closely on what is currently your master branch. When this triggers CI you are getting the benefit of CI - validation and feedback regarding your current code.However if you can't run CI on branches without having your code merged into master or cannot trigger CI to run on a branch, you should probably split your ticket up. Pragmatically a lot of this is going to depend on your team workflow. If you only have a few merges a week the answer is less important than if your team merges 20 times a day. You want to avoid branch drift and particularly CI branch drift if you cannot run CI on branches.is that ticket to large for CI and in turn the ticket would need to be broken down into smaller tickets where each one of those new smaller tickets would need to be done in a day or less?Not strictly required, though it's a decent idea anyways.The point of CI is to run automated processes when you commit/merge code. If you are not doing this, and waiting 5+ days prior to doing so, you aren't really doing CI. That's fine and if that process works for you great - it's just not really parallel to the core ideas of CI. Amazon Web Services has a really good definition on their site (emphasis mine):Continuous integration is a DevOps software development practice where  developers regularly merge their code changes into a central  repository, after which automated builds and tests are run. Continuous  integration most often refers to the build or integration stage of the  software release process and entails both an automation component  (e.g. a CI or build service) and a cultural component (e.g. learning  to integrate frequently). The key goals of continuous integration are  to find and address bugs quicker, improve software quality, and reduce  the time it takes to validate and release new software updates.In the past, developers on a team might work in isolation for anextended period of time and only attempt to merge their changes to the  master branch once their work was completed. This batched process made  merging accumulated code changes difficult and time-consuming. This is  compounded when small bugs accumulate for a long time without  correction. These factors combined made it harder to deliver updates  to customers quickly.With continuous integration, developers frequently commit to a shared  repository using a version control system such as Git. Prior to each  commit, developers may choose to run local unit tests on their code as  an extra verification layer before integrating. A continuous  integration service detects commits to the shared repository, and  automatically builds and runs unit tests on the new code changes to  immediately surface any functional or integration errors.If you aren't doing this, you by and large will not be doing CI - but again, this is dependent on your team workflow. But recognize batching feature changes is nearly the exact problem situation that having CI types of processes were developed to solve (see the Amazon definition).