Is my sprint break down good enough to start with?

Question

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?

Answer 1

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.

Answer 2

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/

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.

Answer 3

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

Answer 4

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.