0

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.

Dimple Sahani
  • 507
  • 1
  • 4
  • 12
  • 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? – Anurudh Singh Oct 05 '15 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. – Dimple Sahani Oct 05 '15 at 13:04

2 Answers2

5

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.

WBW
  • 3,932
  • 12
  • 20
  • But how will I manage so many activities in just 2 weeks sprint – Dimple Sahani Oct 05 '15 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 Oct 05 '15 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 Oct 05 '15 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? – Dimple Sahani Oct 05 '15 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 Oct 05 '15 at 18:13
  • Okay...In a sprint...its like a mini waterfall I believe...is it correct?..can you suggest, how much time I should give for each activity..What I mean is...for two weeks...how much time dev effort shd take, how much time integration+system and how much informal UAT...And Also in my above plan, if I make change to add informal UAT and then have one final testing Sprint and formal UAT sprint and then a production release...Is this plan Okay? Unless ofcourse client demands that he wants an urgent release after a sprint only?And if its more than 2 weeks sprint then you would suggest a formal UAT? – Dimple Sahani Oct 05 '15 at 18:42
  • No, a sprint is not a mini waterfall. Read this question and the answers: http://pm.stackexchange.com/questions/16361/what-are-developers-expected-to-do-during-testing-in-the-latter-half-of-each-spr – WBW Oct 05 '15 at 19:18
  • All your questions are good, you should ask the developers how much time they need for integration and system tests since they will be doing the work. Negotiate a UAT period with your customer (usually 2-3 days near the end of the iteration). If you have a CI pipeline with a manual promotion to a staging environment or can cut a UAT branch you don't need to worry about blocking developers while UAT is occurring. The point is plan not to have a final testing sprint or formal UAT, plan to continuously deliver valuable features to the customer. – WBW Oct 05 '15 at 19:22
  • If you plan testing and UAT sprints, you will have testing and UAT sprints because the team knows they can push off less fun work till the very end. Avoid this mistake all together and set the expectation that work will be fully done at the end of every iteration. Tell your team this is how you avoid the waterfall death march. – WBW Oct 05 '15 at 19:23
  • Okay in each release - I will Keep 3 sprints with UAT and One Sprint for UAT(optional-only if necessary).Then it will deploy to production. Okay so lets say I say that my team has a velocity of say 20 story point per sprint...as per my understanding that storypoint computation covers - development , testing & UAT effort...am I correct?...although story point is relative but for real world use, we need to work out some number of days against these storypoints? – Dimple Sahani Oct 05 '15 at 19:49
  • Yes, your velocity covers any type of work the development team does. So for instance, ff you have a QA specialist working on a UAT story with a customer that story should be estimated and count towards the team velocity. For real world use you do not need to work out number of days to story points. Story points are time ranges, they do not map to discrete # of days and attempting to do this will result making decisions based on false premise. A 3 point story may take on average 5 days to complete, but it may also done in 3 days or 9 days. This is unique to how your team estimates work. – WBW Oct 05 '15 at 20:05
  • 1)If story points has nothing to do with days/hours-20 point velocity may take 5 days in one sprint or 10 days in another.I cannot estimate&cannot do sprint or release plan2)Many stories are epic so we shd break it down,any suggestion to how much broken down story is advisable3)Customers say 500 person hours of developer effort and say come up with tentative plan & later there will be changes so if we don't come up with story point=day/hour,its a problem4)What % of automation is possible,I have read there are tools like Fitness for agile purposes-different from screen capturing automation – Dimple Sahani Oct 06 '15 at 13:29
  • Please create new questions or review the existing answers the community has provided to many of the your questions in the above discussion. – WBW Oct 06 '15 at 15:47
2

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 Ramachandran
  • 11,082
  • 1
  • 22
  • 50