Tasks (much) longer than a sprint

Why would you wish to use Scrum for something of that nature? How do you think empirical process control might have been of benefit, whether it be either for the development initiative, or to replace the algorithm itself?

In other words, are you saying that if a development organization has a task that falls way outside of a sprint, that tasks should not be conducted within the framework? I'm fine with that. I was just wondering the extent to which, and how, an otherwise Agile organization would accommodate this. Let's get into a grey area then - what if monolithic tasks routinely took longer than the designated sprint duration, although still not so many that the sprints' duration would be changed? Let's call it an 'annoyance level' of tasks that 'escape the sprint' but maybe not by much, just enough.

Having never worked on anything for as long (or presumably as complex) as that, I wonder what you were doing with an algorithm for 6 months that you wouldn't have been able to inspect a "Done" Increment at any stage in between.

I assume it wouldn't be 6 months of solid typing, so there must be some point where the calculations are being validated in some way. I wonder if those might be meaningful inspect & adapt moments.

Could you give an example?

[1] First check which is suitable: Scrum, Kanban or Scrumban. In case if you select Scrum then select sprint length as 1 month (That is the maximum possible! ).

[2] There are various techniques to split bigger work to small work 

https://www.scrum.org/forum/scrum-forum/27050/techniques-splitting-user…

Reference: 

https://agileforall.com/wp-content/uploads/2018/02/Story-Splitting-Flow…

https://www.betteruserstories.com/courses/better-user-stories/videos

[3] The INVEST concept - Here is my interpretation of INVEST:

Independent—Each story is a potentially releasable unit of work.

Negotiable—The product owner is open to negotiating the scope and contents of the story with the development team. This allows good ideas from all team members to surface.

Valuable—Each story provides user value on its own.

Estimable—Each story is concrete enough that the delivery team can give an approximate estimate, either relative or absolute, as to how big the story is.

Small—The story can be completed in a short amount of time, so that the team can receive quick feedback.

Thanks.

I agree with @Simon Mayer that there should be ways to break this into small bodies of work.  I've seen work done on extremely complex algorithms dones incrementally.  It would help us provide some better suggestions if you could provide some more information on the algorithms that you are creating.  You don't have to provide extreme detail but even telling us what your algorithms are being used for would help. 

@Lee Fischman,



From my personal experience, I did it with a calculation engine that couldn't be split and touched every module of the main application.

BUT if your team does not have the technology and know-how to work with versioning, automated testing on code and functionality level and code merging you should not even think about starting the below method!

Also there will be a lot overhead, so convincing management of the below method will take some effort.







So we worked with a "Main Scrum Team" on the main application and with a "Project Scrum Team" on the calculation engine. The Sprints are 4 weeks.



1) Both teams start from each from the same Increment, but fork each there own version as beginning point.



2) The "Main Scrum Team" does its normal work in 4-week Sprints (Product Backlog, Sprint Planning, Daily Scrums, Sprint Review, Sprint Retrospective....) on their fork.



3) The "Project Scrum Team" starts with the calculation engine (seperated Product Backlog, Daily Scrums, Sprint Retrospective), only the Sprint Review gets changed into another event, namely the "Increment Inspection Meeting", because the code delivered is not "Done". Their Sprint is also 4-weeks and runs in sync with the "Main Sprint"

4) After each Sprint the new code of the "Main Sprint" has to be merged with the code of the "Project Sprint" without damaging the calculator engine code. So here is where all that test automation comes in. If the calculator engine code does not perform correct anymore after merger, it's up to the "Project Scrum Team" to adapt their code and not request the "Main Scrum Team" to adapt the main code. this cycle continues till the calculator engine was finished.

5) Once the "Project Scrum Increment" is "Done" and the "Main application" code up to that point is merged with the "Project Scrum Increment", the "Project Scrum Increment" becomes the "Main Increment" and the branch of the "Project Scrum Team" is retired in the versioning system

IMPORTANT:



A) Like you can read, it's a lot of overhead, so do not (try to) do this for user stories that barely exceed 1 Sprint length. the mechanism is their that you take the unfinished user stories to the next Sprint.



B) Be very, very, very sure that you really, really, really can't split up the user story anymore!

C) Do not try this if your test automation and your versioning isn't up-to-date (read: state of the art), else it will fail miserably

D) The above modus operandi is only used for exceptional cases, do not make it a standard operational mode! Try to avoid it if possible!