I am first time making an Agile Plan

Following are the sprints I have planned

*Sprint 1 … 3(2 week Sprints)

Sprint Planning meetings, Picking up prioritized stories, Breakup of stories into tasks, Story Coding and unit test case preparation and unit testing, Integration Test Case creation , System Test cases creation , Sprint Testing, Integration Testing,System Testing of this Sprint stories and last sprint stories, Backlog grooming for next sprint, Remaining time for Sprint Bug fixes for this sprint(2nd week), As many bug fixes as possible, pending to be fixed in last sprint

*Sprint 4

All sprints Integration and System Testing On QA, Bug Fixes

*Sprint 5

UAT Deployment, UAT, Bug Fixing, Production Deployment

Please have a look and share your thoughts. Also Team will have developers+testers Developers will be writing Junit testcases and continuous Integration will be used.

After one release 2 more resources will be added who will be working on production release bugs. The release will be deployed with next release only unless there is a showstopper bug.

Also please guide to me how much of Automated testing can be achieved with agile projects as its constantly adding features.

  • Curious to know, if you plan to deliver the software by the end of Sprint 5 and the Product Backlog items are frozen and there is no scope of addition of any feature from the Product Owner or the Stack Holders. Or this would be an ongoing process and the Project would continue for sometime. Will you be playing the role of Scrum Master for the Project? Commented Oct 5, 2015 at 12:46
  • Product Backlog items wont be frozen...In the second week of every week, there would be estimation and discussion of next sprint items. Yes , planning to deliver one release after every spint5, is this seems to be a good idea..this plan is undergoing discussion? I will be Scrum Master. Commented Oct 5, 2015 at 13:04

2 Answers 2


This is not a Agile project plan. You have scheduled the normal waterfall activities into various sprints. The whole point of Agile-scrum delivery is to supply a shippable increment at the end of each iteration. This includes testing and UAT.

Each iteration's work items should have a Definition of Done that commonly includes:

  • Automated testing (integration, unit, performance, etc)

  • Manual testing (exploratory, acceptance, edge case, UAT, etc)

  • Code reviews

  • Architectural and/or design patterns adhered

  • Known bugs fixed

  • Product demoed to customer or product owner

You should have a production deployment at the end of each iteration. If the customer does not support this, your code should be shipped to a staging/stabilization environment that mirrors production at the end of each iteration. The increment should be fully tested before going to stage and stage can be used for UAT activities if the customer wishes to participate.

  • But how will I manage so many activities in just 2 weeks sprint Commented Oct 5, 2015 at 17:41
  • I'm not sure what your role is, but you shouldn't be managing much on an Agile-scrum team. The team members are accountable for most activities in the definition of done above. The only items that actually require "management" are usually those around demoing to internal stakeholders or getting a customer into UAT. Everything else your team members should be doing on their own.
    – WBW
    Commented Oct 5, 2015 at 17:48
  • Team members should be estimating the number of work items they can take into each sprint while allowing enough time for testing (both automated & manual) code reviews, and any work required for pushing to production (should be minimal if you have a CI pipeline). You should not be pushing work into the iteration or schedule work activities for team members. Agile-scrum is a pull-based methodology.
    – WBW
    Commented Oct 5, 2015 at 17:50
  • I am sorry I didn't frame my question correctly..yes, I wont be managing as I will just be scrum master...As this stage , we are just at the proposal response stage where we have to give plan to the customer and we have to tell them how will our sprint and release plan look like...but the point is if a sprint has all the activities - development(few days)+testing(few days..i believe everything cannot be automated)+few days bug fixing + UAT also...so much in just 2 week? Is this manageable? Commented Oct 5, 2015 at 18:02
  • Yes its very possible, although I would negotiate not doing a formal UAT, and just work with the customer to agree to get the customer playing around with the software at least once a week. Your team will deliver fewer work items in the two weeks but they will be completely done including testing. This is less costly in the long-run since there is less context switching and relearning of code at the end of the project. Also your customer should provide frequent feedback and tell you if priorities change or if work items are incorrect, thus saving you any surprises at the end of the project.
    – WBW
    Commented Oct 5, 2015 at 18:13

Plan to complete all work, including UAT, within the sprint

You are taking a big risk if you plan to do all UAT (User Acceptance Testing) for the previous 4 sprints in the 5th sprint. If the users find major issues at the last moment, either your release will get delayed or you will end up taking short cuts in quality, resulting in production bugs.

Your goal should be to create a shippable increment at the end of each sprint. In order to accomplish that, you should plan to complete all of the work including UAT within each sprint.

Keep Work In progress (WIP) down. Start working on two or three stories, take them to completion (including development and all testing) and then take up the next two or three stories. For details see this blog post from Mike Kohn.

You said:

Developers will be writing Junit testcases and continuous Integration will be used

Your team seems to have good engineering practices. So, try to take up fewer stories, if necessary, in each sprint and complete all testing including UAT so that all stories are in ready to deploy condition at the end of the sprint.

Avoid pushing problems from one sprint into later sprints, such as these:

System Testing of... last sprint stories

As many bug fixes as possible, pending to be fixed in last sprint

If absolutely necessary, you can consider a Release Sprint (also known as a Hardening Sprint) as outlined by Mike Cohn.

  • Ashok, how many devdays,testingdays,UATdays should I keep in 2 week cycle...its such a short time...will it not spill over?...Any suggestions? Commented Oct 5, 2015 at 14:55
  • I edited my post and added a paragraph on WIP. Commented Oct 5, 2015 at 19:47
  • @AshokRamachandran What is a dev day, or a testing day, or a UAT day? Why does each day have to be for one activity? Commented Feb 21, 2017 at 3:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.