no working software to demo in initial sprints

What risks and uncertainties in this application would benefit from being brought under empirical process control?

@Vidya Narayanan, As I was reading your post, the first thought that came to my mind was "Waterfall" and it looks like the approach is also waterfall under the guise of Agile using Scrum.

I am assuming that this new development from a legacy platform would involve things being done from scratch. The way to approach this and perhaps ask the PO is can we not integrate some data along with some of the so-called building blocks such that it becomes something that can be inspected and adapted if needed?

Sprint 1 -- Delivered user interface capturing input from user (increment) 

Sprint 2 -- User Interface capturing input from user is now processed through code (so the new stuff here is the code using the data as input which is the addition to the previous increment)

Sprint 3 -- User Interface capturing input from user is now processed through code and the result is stored in a database. 

The above is perhaps a good example to explain the concept of an increment, something that can be inspected etc. In each iteration, something is delivered that is not necessary the whole product but through each iteration it develops and evolves into the final product.

Using the above, is it possible to think of implementing work in a similar manner?

so that agile working software

I just want to correct you here, there is no such thing as "agile" working software.

Thanks a ton  Ian and Steve for answering this before my Monday :) . More importantly giving me constructive feedback on how to rectify this. I will take it up with the po on Monday itself and correct course from next sprint itself as currently task shifting might lead to waste.  Even the po comes from waterfall mindset inspite of a agile coach being here.

But tell me, the customer will not use the semi complete product as they are working on the functional legacy one. Also the UX design will be ready only after July 15. So  will this approach be beneficial? Go live definitely can't be done. I can ask the UX to hurry design for critical screens first . 

I am coming back here at connecting to po 

Steve's approach is already something, but one could also envision:

Sprint 1 - create a register/login screen, that connects to very limited backend that connects to database with 1 table and comes back with a response, thus enabling full user authentication process

Sprint 2 - add product search and adding (or whatever the business is about anyway)

Sprint 3 - add printing...

But tell me, the customer will not use the semi complete product as they are working on the functional legacy one. Also the UX design will be ready only after July 15. So  will this approach be beneficial? Go live definitely can't be done. I can ask the UX to hurry design for critical screens first .

@Vidya Narayanan, Going back to Ian's question and from your original post, if the same functionality is being developed, but only the technology is being changed, does the project really have a lot of unknowns or complexity that warrants the use of Scrum such that the progress of the work happens by learning from feedback and experience?

What I am trying to say is that the iterative nature of Scrum helps accomplish a little bit of a big project, get feedback from relevant stakeholders for that small piece, keep building over the first piece in small increments while ensuring that each increment is tested (to ensure quality, defect free work) and all the subsequent increments done so far are also tested and that they all work together.

The best analogy I can think of is a student (Scrum Team) who is trying to do some new work for his teacher (Stakeholder). The teacher explains what needs to be done, the student attempts it the first time and then seeks validation from his teacher to know if he got it right. if the teacher says no, he takes the feedback and attempts the work a second time and again seeks validation from his teacher. Consider this process to repeat until he gets it right. This is the essence of Scrum and Agile.

Even if the customer is not going to use the new product shouldn't they be involved to see progress? Even traditional project management advises to engage stakeholders early in the project.

One last note, Agile aims to solve some of the problems Waterfall has but Agile isn't necessarily a silver bullet that can fix everything.

But tell me, the customer will not use the semi complete product as they are working on the functional legacy one. Also the UX design will be ready only after July 15. So  will this approach be beneficial? Go live definitely can't be done. I can ask the UX to hurry design for critical screens first .

I'm going to start with this from the Scrum Guide section for the Development Team (emphasis added by me)

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of "Done" product at the end of each Sprint

The increment delivered in a Sprint does not have to be released at the end of the Sprint.  There are many factors that go into determining when a combination of increments are released.  So the customers using the legacy system until the new system is fully ready is not a problem.  As long as they are given an opportunity to provide feedback on the new system as it is being built then you are accomplishing the goal of incremental delivery. 

So the customers using the legacy system until the new system is fully ready is not a problem.  As long as they are given an opportunity to provide feedback on the new system as it is being built then you are accomplishing the goal of incremental delivery. 

+1 to Daniel's comment.

"Using the software" and "the software being valuable" are two different things and this is OK.

I would suggest moving away from working on the "integrated data" and "building blocks" and move towards the kind of valuable features that have been mentioned above.