dev and qa in same sprint

Question

I am not the first one to ask this but i also did not get anything concrete from other such posts to tell me what is needed so i am posing the question here. Feel free to refer to some other resource.

My organization is constantly trying to implement the agile methodology as its shiny but we know we have not implemented it properly. We are currently completing a sprint items by saying that they are dev complete. The QA part of the effort is not required to successfully mark the item as completed in the sprint. This means the primary motive of a sprint deliverable is not achieved.

Now knowing that is different from knowing how to get to the ideal world of a structure that supports true agile delivery.

So what i am looking for is all that is needed to implement the structure that can deliver in agile fashion. A book's reference or an online post or whatever you know has worked for you will be helpful as long as its not just theoretical mention of principles but a practical guide of how to implement it.

The basics like implementing automation is what is being worked on. But that still does not cover for at the least a little time when dev has completed developing vs QA has completed testing the deliverable. How can both be completed by the end of the sprint and neither is remaining but still not have a dev sit idle near the end of the sprint while they wait for QA effort or QA starts some QA work after the end of sprint because dev just finished their work.

Answer 1

How can both be completed by the end of the sprint and neither is remaining but still not have a dev sit idle near the end of the sprint while they wait for QA effort or QA starts some QA work after the end of sprint because dev just finished their work.

There's really no reason someone can't be idle at the end of the sprint, since scrum optimizes for the team rather than the individual.

That being said, I find it hard to imagine any scenario where this would be possible unless it's the very last sprint of a project. Once the development work is finished, the devs simply need to continue to work with the testers to test the product. Software development under scrum is a team sport. If you have a dev that is unwilling to help test his or her own software, or that of their team mates, they don't belong on a scrum team.

Things devs can do after they think their development work is done:

• help write automated tests. For example, if using a keyword-based testing tool, they can write the lower level keywords,
• help the testers with the generation of test data,
• fix issues with the testability of the code. For example, if building a web app, add missing id attributes as soon as the tester mentions it,
• work with the product owner on grooming the backlog,
• optimizing small sections of code,
• help other devs cross the finish line with their code
• help write any necessary documentation

Likewise, I can't imagine any scenario where the QA has nothing to do before coding has finished. Here are some of the many things testers could be doing during the first few days of the sprint:

• working with the product owner to fully understand the acceptance critieria, and collaborating with the dev on how they plan to do that,
• generating high level test scenarios,
• gathering test data,
• making suggestions to the dev on how to make the code easier to test (simple example based on a web application: make sure they add unique ids for every web element you need to interact with),
• collaborate with the product owner and dev to help refine the high level testing scenarios,
• start working on the automated tests. With the right testing frameworks it's fairly easy to write automated tests before the software is ready, if you and the developers have been collaborating all along on what elements are on the web page or in the app, how they are identified, etc,
• reviewing the code that is being written so that you are prepared to test it once it is ready to be tested,
• working with the product owner on backlog grooming and writing acceptance criteria for the following sprint.

Answer 2

...But that still does not cover for at the least a little time when dev has completed developing vs QA has completed testing the deliverable...

The key to a sprint is that the team are collaborating all the time. So at the start of the sprint, testers work alongside the developers to understand what they are doing with the first pieces of work, so as to better know how to test. Those pieces of work should be hours-long, not days-long, so that testing starts almost straight away.

As they test, the testers are providing feedback and the developers are then fixing issues found. So the developers haven't finished until testing is finished. There is no "at least a little time when dev has completed" until testing has finished too, unless that testing is finding no issues, in which case the testing serves no purpose.

The problem of testers having nothing to do at the start of a sprint and developers having nothing to do at the end only occurs if each task in the sprint is treated as a mini-waterfall. So don't do that. Instead, treat each task as a collaborative effort between a developer and tester.

Answer 3

Let me suggest a different approach than the ones mentioned already. When QA shall remain a separate team or department, you may consider to work this way:

We are currently completing a sprint items by saying that they are "dev complete"

That is fine, so whenever you have completed your sprint, you have a new release you can deliver to QA. Let's say this release has the version number 5.0. QA will then start testing 5.0 with a focus on the new features from the previous sprint. Meanwhile, your devs start developing the next sprint, lets say they aim for 6.0.

Whenever QA finds a serious defect, it is fixed in the "5.x" branch as well as in the current dev branch. This may result in an intermediate release 5.1, 5.2 etc to QA after fixing a set of defects. You will have to plan your sprints to have some time reserved for such bug fixings (but you would need such time also if not your QA people would find the defects, but your devs in the current sprint). Fixing the bugs in two branches instead of one will often require only a little bit more time than fixing it in the dev branch, since once the root cause for the defect is found, in most cases it will be just fixing the bug once in the dev branch, merge the fix also back into to 5.x branch (using your version control system) and create a new release in the 5.x line automatically.

When QA has ended testing for the 5.x line, the final release can be deployed to production. Note that not every defect found by QA needs to be fixed immediately, it is perfectly possible to put certain issues into the backlog if they have a low impact.

As you see, this model does not require the devs to sit around and wait for QA to complete. If QA completes testing of the 5.x line before the new 6.0 release is ready, I am sure they will be happy to invest the remaining time into test automation, think about new tests to improve the test plan, or work on the documentation or tools. It will allow you to work in sprints, in an agile fashion, for the price of having a "production ready" release with a delay of approximately one sprint.

Answer 4

This is often a bit of a mindset change for a lot of people. The simple answer is that the team is responsible for developing AND testing something in the same sprint, if that's too much work then they need to commit to less functionality.

Imagine work as a grid, each row represents a feature the team wants to implement, each column represents the various traditional stages. Dev, Test, Resolved, Done etc...

In a typically waterfall application the team would do the Development for all the features, then move into Test, Resolved... as I'm sure you know this approach often leads to large amounts of rework and poor communication.

A scrum team should contain all the skill sets to take a piece of a work from plan to Done (Done, should - unless you can argue a REALLY good reason should mean done and in Production with live customers).

So, instead of completing one entire column a team aims to complete a small number of rows at a time. Finishing a few of these each sprint and pushing them into live before starting the next set. There are many, many reasons why this is a good idea which I'll leave out of scope for this answer.

So, now we know that we want to take your small number of features from Ready to Done we can look at your question - how to help your team both develop and test in the same sprint (I also want to include deploy in this).

Firstly, make work visible. If people can see all the work that is required to get these features into Production then you'll stand a much better chance of completing it.

Next, it is the entire team's responsibility to complete the tasks. Testing isn't one person's responsibility, it's the entire team's jobs - sure some people may have more testing expertise but they can assist other team members, they are not the only people who can test.

Changing mindsets/culture is hard, but here are my main suggestions:

• Take a small number of small tasks and deliver them to live each sprint
• If developers find themselves with nothing to do don't let them pull in more work, they need to help the testing/deployment process
• Get testers involved early, use your refinement/planning sessions to identify the tests that should be run. Having tests like this planned out makes it much easier for non-testers to get involved in testing. Encourage developers to automate tests!

TLDR

Encourage the team to deliver to production each sprint, this will naturally balance itself out for people to pick up less work but push it all the way through.

Think of your team members as engineers with different skills. There's no reason developers can't test and testers can't advise on development in progress. Planning the tests to be carried out as part of your Definition of Ready makes it much easier for testers to design tests for other team members to carry out.

I strongly recommend your Definition of Done includes getting something into live and stories are not closed until they are in production. This makes work piling up in test/awaiting deployment extremely visible and encourages frequent releases.

Answer 5

Here's some practical advice on how to get DEV and QA in the same sprint.

1. Small stories. Anything bigger than a 3 gets broken down into smaller stories. Ideally there should only be 1- or 2-point stories. Consider 5- or 8-point story. Dev has been 8 days coding, and you only have 2 days to test in a 2-week sprint. Not going to be successful.
2. Feature flags - Some items may not be able to fit into a sprint, so the team may progress on the feature but it not finish it. So, you want to show progress but not turn it on in prime time. This helps with efforts that span multiple sprints.
3. Scheduling/Organizing work. Ideally developers would work on larger stories at the start of the sprint, shorter ones at the end. If there are 3 days left in the sprint, maybe picking up a 1 point story is more prudent than a 3 point one.
4. Measure/Retro - If the team commits to 30 points for DEV/QA in one sprint but only gets 20, then Retro on what you can do better. The point of agile is to consistently deliver value, so when you come up short, figure out why. Maybe overestimated, too much churn, etc.
5. Always plan for something to not go as planned. So, set realistic goals and refine them after a few sprints. A new team will not know it's capacity and output until a few sprints of measurement and retros.
6. Always have an active backlog. The thing with agile is that if someone finishes early, then just pick the next story in the backlog to work on. You may find that QA can't keep up with DEV or vice versa. Finding the right amount of QA and DEVs will be crucial to keep the team balanced.
7. Devs do most of the testing via automation. If you don't have automation in place, it will be harder to do DEV and QA in the same sprint.
8. Your product owner should also validate the functionality as well. Not really done until business/product owner signs off, so they need to be an active participant.