Vertical Slicing techniques for user stories in ETL (DataStage to Abinitio) migration Project

You say that scope is already defined. What uncertainty is there, which can then be brought under control, Sprint by Sprint? Any "slicing" of work should help the team frame and meet Sprint Goal commitments for this purpose.

Ian as I mentioned, the Scope is more or less like end outcome rather on incremental wise. "We already have scope defined, i.e. migrate all the jobs from DataStage to Abinitio so that DS will be shutdown for end users" 

This is what the Org would like to see down the line after 4 months. And to achieve it, we are picking it up in chunks (each module and migrating) and pushing to prod every 2 weeks. This scope is very clear and we are aligned with it. 

My question was rather on the user story side. When the team picks stories, during planning session, the activities / tasks involved to achieve the HOW part will be created by the team. As of now, we are following very basic way to do it. Is there any thing specific to ETL. Having this will not accelerate our release cycle or the other way around.

Thanks.

Ian's response is - as always- deep suggestion whether you need or not Scrum (when there is no uncertainty, there is no need and maybe no value in "doing Scrum") :) This forum you can receive expertise regarding Scrum itself. 

Let me try to help you with your case, although bear in mind, that this mentoring requires to be adjusted and validated via number of experiments in well run Scrum.

My experience here is as follows: you move concepts (data pipelines?) from one BI technology to another BI technology. The uncertainty (which is important factor to consider when using Scrum, as suggested by Ian) here is usually "what is done in technology A, could we also do this similarly in technology B?" or "this ETL mapping is specific for technology A, how could we design and implement it in in B". You should probably split your work vertically per full data pipeline (something that may require to design part of dat model, provide dta transfromation, cleansing, mapping etc.). This is your full user story.

To split this story to smaller stories, when required, you could consider r&d work "how to do it in B" or to consider to implement general case first, and then to add additional stories to enrich the process by cleansing, special cases, data validation etc.

vertical story (full data pipeline) --split1-> spike (r&d) + work

vertical story (full data pipeline) --split2-> basic case + cleansing data + data validation

From your explanation, it seems the project is more technical and not much of end customer facing. SInce your team knows the end goal to be achieved(like the total number of jobs to be migrated) and all you want to know is the 'How to do' part.

Here I agree with Ian and Tomasz as your team needs to figure out what problem you will address by doing in Scrum way because you may not have a definite increment as such to create in every sprint.  And if you want to create Product Backlog items for each job separately, Then you can think to work with Kanban principles. This way the team can look for the throughput to measure how many jobs migrated in given time so that helps to estimate better.