Non-tested product in the end of Sprint in Scrum methodology.

Question

Hi guys!

Here's a problem. Developers have some kind of a task (develop certain feature), which takes about the length of a sprint. So, by the end of the sprint developers are happy since they just finalized their part.

BUT. The product is not QAd, so it can't be distinguished as "potentially shippable" since it most likely will contain some bugs.

So, the question is: if there's NO automation tests, only human QA engineers, what's the best way to plan our sprints? To have one sprint of a delay (QA tests the items that were developed in the previous sprint)?

What can help us out in this kind of a situation? What should developers do during the QA procedure?

Answer 1

You may need to change the length of your sprint, and define done as gone to QA, or ready for Production.

This is hard to do, but that also means making certain you have tasks on the board for testing.

Also, this will mean scaling back, so during the mid-point check be honest and remove the tasks that won't be finished, in order to achieve the definition of done.

Or, and this is less ideal, basically have two sprints/feature. The first should be to get it working, with unit tests, and the second is to get it through QA. So, the second sprint may be shorter, but, if you are going to do that then just combine them into a longer sprint.

Answer 2

Your tasks are too big. You need to have smaller tasks (a few days max) that bring value to the customer (so that they can be tested). When a task is done, from a development perspective, QA can start validating it.

Perhaps you need also to plan less for a Sprint, so that increment gets validated at the end of the Sprint.

It's not uncommon for team transitioning to Agile to have QA validating what was developped in the previous iteration. But they have to catch up.

What should developers do during the QA procedure?

There is no phase with Scrum, developers code while testers are validating, and testers are testing while developers are cranking code. When the development of the planned tasks is complete, they can write documentation, fix problems reported by QA, support QA, estimate tasks for the next Sprints ...

Answer 3

We do QA on individual features during the Sprint in which they are developed. At the end of that Sprint we make sure our Main source code branch is up-to-date and then developers carry on with the Dev branch. This frees up QA to do Release Testing and doesn't time-box them. Any bug-fixes can be easily applied to the Main branch without having to 'undo' any new stuff in the Dev branch.

Your bigger problem may be lack of automated / Unit testing. This cuts down the amount of work your QA guys have to do and will, therefore, make it more likely that they finish their work quicker.

I also don't think that increasing the length of your sprint will help. This will force you to either add more developer tasks or have your dev guys sat on their hands whilst QA catches up.

Answer 4

Unfortunately, but you just aren't doing scrum. You are doing waterfall in sprints; aka scrum-fall.

1) Integrate QA into the team. They shouldn't be a separate group that you "pass" the code to. They should be working with the devs every day to test their work.

2) Make your stories much, much, much smaller. A story should take 1-2 days to complete (a week is absolute max and only occasionally unless you're building rockets). You need the team to work on getting better at slicing functionality vertically to create small testable, usable, value added stories.

3) Scrum doesn't have job titles. If a dev is done doing all coding then he/she tests someone else's code. Or works to create automated scripts that you say you are missing.

4) Its OK to have a "hardening" sprint right before a major release, but certainly testing HAS TO BE done during the same sprint as development. Pretty much every time code is checked in, testing gets done.

5) Fix your definition of "done". Done means the code is written, tested, deployable, and documented as needed.

6) You need a lot of work on "team" and commitment. Your comment that devs are "happy" as long as their coding is done is quite contrary to scrum and its principals.

Based on your comments I think the team needs to invest in training if you are serious about becoming agile.

Answer 5

A very important aspect of Scrum is getting things "done" during the Sprint, and the definition of done. If a feature is finished during the sprint, but not tested it still isn't done.

What you should not do to solve this is to increment the length of your Sprints. Short sprints would still mostly be prefered. I'd suggest two things.

The first one is really important, but not necessarily easy to achieve. Integrate QA into your teams. Having a separate QA department that validates your product after you're "done" with it is really waterfall. You may still want the QA verification before your product is shipped, but what is produced in the sprint should be finished and tested during the sprint. To do so you need qualified QA people to be part of your team - or you need to train the developers to do QA as best as they can. In my company our QA department is too small, so we were unable to get some for our team. Instead we learned about QA and added a column to our task board with the heading "Ready for verification". Whenever a feature was finished it was moved to "ready for verification", and some other developer would look at this. Even though we might not have been as skilled as the dedicated QA guys we discovered problems all the time this way, moving them back for fixing, and then to Verification again. This process gave us much more confidence in the features we classified as done during the sprint, and a dramatic drop in bugs found later on.

The other things is to start defining smaller tasks, or do a better job in breaking features down into smaller parts. You don't want to work on a feature that accoring to your esimations might take the whole sprint. If your "almost done" you really haven't finished anything during the sprint. Instead; break the features down into smaller parts and solve them one by one. While someone is working on part2 part1 is being verified by one of the other team members, making the whole process of development and QA more integrated - giving a better chance of calling your new features "done" at the end of the sprint.

Good luck!

Answer 6

Define done as developed and tested (no bugs,or any other acceptance criteria). Integrate testers into your team. As feature is being planned for sprint divide it into small tasks and make testing one of those tasks (or even more than one testing task). So You will have feature A consisting DB changes, UI Changes, App changes, Testing - all tasks adding up to one feature. Additionally engage testers as early as possible, don't wait till end of development. And when Testers are still testing, and developers have finished their tasks (there always will be some time gap between development and testing) move developers to work on other feature.