-2

In the previous question, plan of release was discussed -

  • 3 sprints, two weeks long each
  • staging deployment and UAT in each sprint
  • optional hardening the sprint and at its end production deployment
  • release completion

If I further break down a sprint, it would look like this:

  • sprint planning: 0.5 days
  • development effort (by developer): 5 days, in parallel
  • integration or manual test of this sprint (by testers): 5 days
  • integration or system testing : 2.5 days
  • user acceptance tests : 2 days
  • sprint retrospective
  • separate team for automated testing for previous sprints that is decided to be automated

Can I proceed like this?

  • 1
    Could you edit your question, so it contains the information from your previous question? As it stands, your question is hard to answer. Your 'bottomline' question should make clear what your trying to achieve and why. – upstream Oct 13 '15 at 12:54
  • Rieks, I have updated it...hope it is clear now – Dimple Sahani Oct 13 '15 at 13:06
5

Mini-waterfalls aren't Scrum

What you are implementing is a mini-waterfalls approach where you have multiple small waterfall development efforts. If that is how you want to run your team then I'm not going to tell you it's wrong. But, this is not Scrum. If you want to run a Scrum process you should be looking to deliver completed enhancements throughout each sprint.

You also need to let the team organise themselves within the sprint to get them working together, most of the time, to achieve the work in the sprint. Hopefully this means people are working together and collaborating on stories most of the time, as opposed to testers waiting until late in the sprint to do their work, or developers twiddling their thumbs for the last couple of days.

Comparison of mini-waterfall vs. Scrum

This section will try to answer some of the follow-on questions from the comments sections.

In a mini waterfall the first few days may be spent by the devs working out how they are going to build something (design) and ultimately building that thing. They may work together or separately on their enhancements. During this time the testers are likely writing the test cases for the work the developers are doing. Once the development work is done, the testers can start testing it. Hopefully there is enough time left for them to do all the testing they want and development didn't overrun. Developers can now spend their time fixing previously logged bugs, which the testers can then confirm are fixed. As bugs come in from the testers on the new enhancements the developers fix those. Again, hopefully the testers don't find so many issues there isn't time to fix them during the sprint. If something is found to be seriously broken and needs to be rewritten (maybe the original design misunderstood the problem) you need to squeeze in another dev-test cycle in the time remaining.

With a Scrum approach, on day one you still do some planning of how work will be done. This should include devs and testers. Testers can highlight things they would look to test for to make sure developers consider those things in their plans. This can also allow the testers to identify small chunks which the developers can deliver to them early for testing. Any test cases needing to be written should be included in the plan for that story. After this is complete the team gets together to work out what pieces of work they will all pick up first. This is repeated each day in the 'daily scrum' meeting. The team will usually not work as individuals on their own enhancements, where possible two or more developers will split up an enhancement to work on in parallel. If all the developers suggested they were about to start work on things which would take them 3 days before there was anything worth testing, the testers should speak up that they need something to do. Possibly some of the quicker bugs to fix need a lot of testing, let's get those fixed first to keep the testers busy while we work on something bigger.

Hopefully this allows a more efficient use of the teams time. I think the situations where the test cases take exactly as long to write as the code are rare. By splitting the work up and allowing the team to decide on a daily basis what they work on they can optimise the use of their time and work together to achieve the sprint goal. The benefits of working like this are many, too many to go into here.

  • Robin ...I am not able to visualize what is the other way?...do u mean each story has separate dev, testing and UAT?...I don't know what is the other way? – Dimple Sahani Oct 13 '15 at 13:43
  • Each story will need coding, testing, etc. But you don't operate your sprint with dev, followed by testing. Instead you try to do a mix of all throughout. You also split up stories and deliver small chunks from dev for testers to start work on. So, on day one of the sprint you should have some work for the testers to work on, and on the final day the developers are hopefully still producing new code. So a 10 day sprint has more like 9 days of coding and 9 days of testing. – Robin Oct 13 '15 at 19:09
  • Robin, but when will testers write test cases and when will UAT happen if all the time is utilized like this...generally when developers are writing code, that time is utilized by testers to write test cases and later on during UAT time- developers fix bugs given by client and also during internal testing time, bugs are fixed by dev team...so okay ..it was waterfall so I have to do away with it so what u explained I got it but I didn't get that how I implement it because the activities which I have just told you - when will I do that or how will I do that....i know my question is too basic – Dimple Sahani Oct 13 '15 at 19:41
  • I want to upvote this answer, but I'd like to see it say "working together most of the time" to make cooperation and collective ownership the point, rather than the level of utilization. If you decide to make that important distinction, you'll get a +1 from me. :) – Todd A. Jacobs Oct 14 '15 at 0:07
  • @DimpleSahani I added an example to hopefully answer your questions. – Robin Oct 14 '15 at 7:46
3

Here’s how traditional test phases typically fit in with an agile testing approach:

  • Unit testing is still completed by developers as usual, but ideally there’s a much stronger emphasis on automated testing at the code/unit level.In eXtreme Programming (XP), there is also a strong emphasis on test driven development, which is the practice of writing tests before writing code. This can start simply with tests (or ‘confirmations’) being identified when a ‘user story‘ is written, and can go as far as actually writing automated unit tests before writing any code.
  • System testing and integration testing are rolled together. As there is at least a daily build, and ideally continuous integration, features can be tested as they are developed, in an integrated environment. As per waterfall, this stage of testing is ideally carried out by professional testers, as we all know developers can’t test for toffee! Importantly, though, each feature is tested as it’s developed, not at the end of the Sprint or iteration, and certainly not at the end of the project.
  • Towards the end of each sprint, when all features for the iteration have been completed (i.e. developed and tested in an integrated environment), there needs to be time for a short regression test before releasing the software. Regression testing should be short because automated, test driven development, with features tested continuously in an integrated environment, should not result in many surprises. Hopefully it should be more like a ‘road test’.
  • Reference : http://www.allaboutagile.com/agile-testing-versus-waterfall-test-phases/

Story Task Breakdown Reference : http://www.slideshare.net/rallysoftware/how-to-fit-testing-in-the-iteration-2009-09-11in-the-iteration-2009-09-11 I suggest you to go through the slides in the mentioned link. Its a good presentation and will give you good idea.

0

Looks good to me. You can do a retrospective on this process after a couple weeks, and see where you can improve it.

0

TL; DR

Probably not. It would appear that you're doing some kind of weird "Scrummerfall" with command-and-control assignments and time-based release planning. This isn't Scrum, it isn't agile, and the comments lead one to believe that agile may simply be the wrong methodology for your team because the team and its leadership currently lack the experience or coaching required to implement successful agile iterations right now.

An agile framework might be a viable choice in the future as the team learns more about agility, but trying to bolt agility onto your current project is unlikely to be a successful project-delivery strategy. Your mileage may of course vary.

Effective Scrum and Agile Practices

Each agile iteration is a "project in miniature." Each sprint should pull in just enough stories to fill its projected team capacity. The team should then take collective ownership of the stories during the sprint, do just enough planning to address the current Sprint Goal, and work cooperatively to complete each story.

While there are exceptions (generally based on team composition and skill set), agile stories should typically be worked on cooperatively by the entire team, not serialized within the sprint and certainly never serialized over multiple sprints.

While Scrum doesn't mandate this, in effective agile implementations your testers and programmers should be working interactively throughout the sprint to implement test-driven design and continuous integration. Planning "testing sprints" is usually a project smell.

Agile Release Planning

Finally, assigning timeframes and tasks is a command-and-control approach that isn't agile. Agile release planning requires a very different approach estimated in iterations. See this related answer for an in-depth treatment of agile release planning.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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