I am a Automation Engineer. I use QTP for Automation. I wanted to know couple of things.
You don't try to "complete automation". Instead, you have stories just like everyone else. You might have stories strictly for automation, or better, automation is part of the acceptance criteria of a user story.
You are (or should be) part of a team for which automation is part of what is delivered. Your work doesn't stand apart from your team. Together you should decide what you can deliver as a team.
A two-week sprint shouldn't mean "we can write the code in two weeks", but rather "we can write the code and test it in two weeks". If you can't do that in two weeks, either you need simpler stories, better team members, or longer sprints.
As for API testing, pick an appropriate language and start writing code that calls your API.
A quick google search revealed QTP as a GUI robot. Such tools are black box testing tools, testing the compiled binary of the application simulating a user pressing buttons, entering values in some fields, checking the results shown at some other fields etc. Typically, you don't have to know in which programming language the original program was written. Creating such tests typically only makes sense after the GUI parts have reached some level of stability.
When talking of API level tests (as opposed to GUI robot tests), we are talking about white box tests of the GUI logic, not through the GUI elements itself, but through an API layer of the application which is very "close beneath the GUI". Such an API layer is most easily created by applying the "Model-View-Presenter" pattern. This pattern allows testing in a presenter-first approach, which makes it possible to create automatic (unit) tests very early - when doing TDD, earlier than the code for the GUI logic itself. Those tests are typically written by the developers who are writing the presenter, in the same language as the tested application itself, and you typically need only something like a free xUnit testing tool, not more.
To my experience, both kind of testing approaches can test different things. But both approaches can also be used to test a lot of overlapping requirements, in case where I would clearly prefer API level tests (my former experiences with GUI robots were, lets say, a bit disappointing, too much effort for too less benefit). But your mileage will vary.
Concerning Scrum: I have never done that, but I suspect tests using a GUI robot tool are best written after each sprint, while API level tests should be part of the development during the sprint.
