Our team has recently adopted agile practices and most of the team is new to agile.In our product, we use some code developed by another team and only they maintain that code. For the last 4-5 years, the previous developers have merged the code they intended to use and not all of that. Over time, the code in our branch was customized as well. Now for 3 years, these code bases have not been merged. We are expecting a lot of changes and manual conflict resolve process to perform a merge, as all of us are new to this code and also the code has been out of sync for long time. How should we approach this kind of task/story in Agile way? Is there any guidelines to approach such unclear task where uncertainty is very high and we do not know how many conflicts/bugs will come out?EDIT:1please bear with me if question is not clear, let me know in comments and i will try to clarify as much as possible. So lets me try one more time. As a AGILE team what I (and team) has learn so far is, before 2 week sprint starts, we discuss requirements with PM, understand the work needs to be done, finalize the approach for any DB design if and then two week sprint starts. in the middle one day we also do another PBR session where any new concern's can be raised for current sprint or we just continue understanding new stories for next sprint. On the last Day of Sprint we do Sprint Demo, and next Day Sprint Retrospective. Recently I came to know word Spike. many AGILE teams use the Spike as a 2-3 days of period between sprints either at the end of sprint to finish up minor remaining task and do not need to carry the whole stories to next sprint. Or Sometimes in the beginning of sprint to finalize the design/approach or to flush out Proof of concept kind of thing. When I (team) saw this code merge task, we are like there is no way we will be able to break down this story to confined task as 90% of things are unknown. we do not have automate test around the code, we haven't merge this code before and again this is a Baseless merge on SQL side. what ever we estimate there are highly chances that we good amount of task may remain incomplete. now in retrospective this will become bad on team. and such task can disturb team velocity as well.So My question is How other people include such task in there AGILE team. Does this really be executed as SPRINT? or this should be one time effort by team and not logged on AGILE board? In a way i am looking for guidance on how AGILE allows to execute such task. If not Sprint is there anything else ? 
How do I handle merging code that hasn't been merged in ~3 years in an agile manner?
agile;maintenance;source code;legacy;configuration management
There's nothing agile about a 3-year merge.Your team is going to have to put agile aside for a while, probably considerably more than a single sprint.  You're going to want to freeze current codebase before you merge and extensively test, so you'll know that the starting code is fully functional.  Then you're going to have to do the full merge, introducing no unrelated changes for its duration.  Then you're going to have to test at least as well as when you started, because no matter how hard you try, you will introduce bugs.  Once you've got that done, you can go back to being agile, but all that stuff in the middle is a classic waterfall solution to a classic waterfall problem.  Oh, and be sure to tag the repository immediately before and after the merge - for a year or more, you'll be blaming every weird bug on that $#@#@$#^% big merge we did, and you're going to want to re-examine the changes to convince yourselves that you're wrong.