Enterprise moving to Agile Adoption

The only expected output from a Sprint is Potentially Releasable Increment so list down the activities required to make your software releasable every Sprint and decide your Sprint length accordingly, should not be more than 30 days.

Also find out what is stopping you from releasing your software every Sprint and work on removing those impediments.

Your testing functions like Automation all should be discussed in Sprint planning, it will go as an Item in Sprint, which will be estimated and worked on. Testing could be one of the item in Definition of done to complete a User story/task.

This may sound obvious, but as the potentially releasable product is expected at the end of the Sprint, the options are limited - so either cut-short on your test scripts to choose most important ones first which can be done within 2 weeks OR increase your sprint duration to max 4 weeks.
In my experience, many projects do not necessarily deploy at the end of each sprint, but by running the sprints keep the things tidy until a point comes where you decide its the time to now go live.

Pankaj

> With most enterprises adopting Agile, how does the horizontal
> testing functions like Automation, performance, Test
> Data Management get aligned to the two week Sprint?
Example: In some cases, the Test Data itself could take a day
> or two with limited environment availability.

Can you clarify the issue here? Why would a couple of days work on certain tasks needed for a Done increment cause an problem?

Thank you for the response.
The problem is that, we have a Horizontal team accpeting the requests from all the applications, working on them and delivering it. With Organization focus towards Agile, how does the Horizontal teams fit in Agile? How will they operate in an Agile mode? Can they still continue being Horizontal?

The best strategy is to form feature teams, each of which has the skills to complete a vertical slice of integrated and usable functionality. That is how MVP increments are typically framed and delivered. Deferring delivery until horizontal slices are integrated is a difficult thing to reconcile with agile practice.