Moving from 2-week dev sprint / 1 week QA sprint model to a "true" 2-week sprint model - tips?

Question

First some background:

We have a team of ~18 devs working across several projects large and small (it generally breaks down to 3-5 scrum teams). We are all working in the same codebase and our sprints are aligned, give or take 24 hours due to scheduling challenges. We have a global code freeze 8 days into our 2-week sprint, after which there is a 1-week QA period. (Meanwhile, the dev team moves onto the next sprint.) At the end of 3 weeks we release.

(Already you can probably see a number of problems with this approach. Without getting into details, I'll just say that it has been a business-driven evolution.)

For us, the biggest challenge is the dev/QA disconnect during the overlap period. In short, with the dev teams jumping into a new sprint and QA checking the previous sprint, the capacity planning becomes very difficult. Devs commit to X number of points in the new sprint and then they get slammed with bugs from the previous sprint. The new sprint then suffers.

What we WANT to do is move to a true 2-week sprint model in which all development and QA happens within the 2-week timebox. Again, many reasons to do this which I won't get into here. For us it's mostly about quality and working towards continuous integration (we would release every 2 weeks instead of every 3 weeks).

I just wanted to see if anyone has had to pull of this bandaid and what kinds of challenges they encountered along the way.

Answer 1

Having gone through something similar myself, here are some considerations. I'll try not to get too wordy but there are some aspects of Scrum that need to be brought up.

1. Making this sort of change can be extremely beneficial, but first and foremost needs buy-in from the developers. If they are not supporting changes it won't work, and Scrum should be run by the devs.

Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness. http://www.scrumguides.org/scrum-guide.html

With that in mind I would make sure (if you haven't already) to bring up the challenges your current process is having, review the scrum principles and the reason they exist, and then ask the dev team what should be done to make this work. Guide them in the right direction instead of telling them, and the team will be far more successful. Like I said you may already be doing it that way but it's worth mentioning.

If you can show success through your empowered team making improvements it will also help you push further change and acceptance on the business side.

2. The main process change to help this work is to involve the entire team as early as possible. What I mean by that is make sure that the devs and QA are working together from the start of the sprint. They should all be present in scrum meetings, and working together to complete the sprint goal. The best way I have found to do this is as follows:
   • Make sure each member of the team knows the business side of the project, the why, the use case, and the value it will bring. Give them the opportunity to ask questions early on ( I actually prefer to have this happen before the product owner has even shown anything to stakeholders, executives, and customers. That is not always necessary if you have an awesome PO though.)
   • Have QA review each story before work is started (so in backlog planning or in sprint planning) and have them add their acceptance criteria. This will ensure that QA is familiar with the task, and that the devs are thinking about what it needs to do before they even start coding. It will also create a conversation early if there is confusion as to the desired outcome, and make it clear devs and QA should be working together.(One thing I like to do here is give everyone the rest of the day after sprint planning to review the stories, get in the code, research, add notes etc... and then give them the opportunity to ask follow up questions the next day. This can be very helpful to frontload questions to the PO as well, so those don't all come at the same time towards the end of the sprint).
   • Break the stories down as small as possible. This will ensure that stories are coming to QA very quickly and steadily, so that they can be testing basically from day one of the sprint. This will also encourage the developers to test their own code (which they should be doing) before it gets to QA and reduce QA's load at the end of the sprint.
   • Push the idea that the entire team (dev and QA) is responsible for achieving the sprint goal. Adjust your scrum board's columns if needed, but make sure the team understands that it is the entire teams responsibility to get the scope of the work in the sprint completed. This is one of the main reasons Scrum does not recognize any other title than developer on the dev team team.

     Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;http://www.scrumguides.org/scrum-guide.html

The reason for that is not to make things more difficult, but to ensure the team works together till they have achieved the sprint goal with their Definition of Done.

3. You mentioned the devs commit to the sprint work. As part of what I said above, make sure that Dev and QA commit to the sprint work. They are in this together and need to be supporting each other equally. QA work needs to be reflected in your estimate.

4. Again, bring these things up in retrospectives. Get ideas and buy-in from the team. Show improvements to the business so they see how empowering the team is effective. As you make changes find out what works and what doesn't and adapt, be agile. Remember that Agile and Scrum are frameworks, meant to provide you with ways to quickly make great changes to achieve the best quality of work that meets the customers needs.

As a final note, remember that Velocity is not for comparing team progress against each other, or to report to the executives on by itself. It is to determine how much work the team can do in a given sprint.

Answer 2

Some suggestions:

Automate as much as possible of your regression testing. This leaves the QA's free to focus on new functionality. This then allows the team to test as they go along in a sprint, rather than waiting for the end.

Think carefully about the way you use version numbering and environments. For example, some teams I have worked with will do a drop to a QA environment every few days in a sprint. It is important when you take this approach to raise bugs against a given version so that there isn't confusion with on-going work.

Look to integrate continuously between the teams. Don't wait for the end of the sprint to do this. Even better, combine continuous integration with regression test automation to get regular feedback on the merged code.

Also, plan carefully. If you want to be testing throughout the sprint you need to have small stories with no dependencies. Always have the conversation during planning about what you will test first and how quickly it will be ready. For example, a team might target having the first few stories ready for testing after 2 days of the sprint. If you have a story that will be particularly difficult to test then there is no point starting testing on the last day of the sprint. Look to tackle it early in the sprint with sufficient time to test.

Finally, encourage communication between team members. Stop thinking of testing as a QA activity. It is a team activity and involves everyone (including the Product Owner).

Answer 3

Obviously your first hurdle will be getting buy-in, both from upper management and from the Team. But assuming you already have that...

One problem you might run into is QA being under-worked at the start of sprints when there's not much to test, while the developers are under-worked towards the end, when most of the stories are in QA. While 100% utilization is a fallacy, severe under-utilization is hardly desirable either.

There are other Q+As about this, but the basic takeaway is to try to find alternative tasks to fill up the lighter schedules. Ideally, developers should be able to help out with testing, and QA personnel should be able to help out with development. Of course, in reality one or both of those are often nothing but a pipe dream.

That being said, there are things both developers and QA personnel could do to productively fill up their time, including but not limited to:

• Writing more tests (be they unit, integration, acceptance, whatever).
• Performing spikes.
• Researching new technologies.
• Addressing technical debt.
• Backlog refinement.
• Working on smaller/lower-priority side-projects.

Also, worth noting: you mentioned that you currently have a triweekly release schedule, and are moving towards two-week sprints. Have you considered three-week sprints? Such could be essentially the same as what you are planning, only without messing up your organization's entrenched release schedule pattern.

Answer 4

I have encountered a few similar problems in one of my projects. Like yours, one of my team had testing efforts piling up towards the end of the sprint. When stories were incomplete (i.e, testing not done in this case), it caused stories being carried forward to the next sprint, disruption to the flow, delay in delivery, coordination issues(between QA and Dev), chaos etc.

The way I came out of this is by developing this mindset what we commit in a sprint HAVE to be finished within the sprint .
Ask the team to estimate and choose the stories that they think can develop, test and deploy-ready within the 2 week timebox.

It is difficult to make this shift, but teams become better as they practice this a few sprints. To start with you might have business complaining about slow delivery, team not coming to a conclusion easily, and much more. But do it gently and slowly.

Indispensable factors to focus on:

1. Start your sprint with planning.
2. Set a Sprint Goal.
3. Make stories more granular, smaller and TESTABLE.
4. Plan together as a team (Developers and QA both involved)
5. Estimate a task/story considering development, testing, deployment (scripts, config changes, etc) - all aspects to get that story to live or align wit (DOD)definition of done.
6. Coach the team to do BDD or TDD which promotes QA involvement early in development.
7. Retrospectives are very useful in situations like this so you understand what is working and what is not. Adapt accordingly.
8. Improve the process, but introduce improvements slowly and gradually only. Do pre-planning, backlog grooming once things are stable. Bring some rhythm to the process.(I've found this so useful as it helped me to manage business expectations better than before.)
9. Measure progress - I used burn down chart every day in start up to bring to everyone's attention any delays.
10. Truly and wholeheartedly support the team as changes/shift in ways of working can cause morale/motivation issues.

Hope this helps.

Answer 5

You have made a critical error in your understanding of how this will work.

You are not going to be moving from a 3 week release cycle to 2 week. You are moving from 3 weeks to 6 weeks.

The problems you experience with developers commiting to a sprint and the "being slammed with bugs" are not due to a disconnect between them and QA but due to adding tasks to an in progress sprint.

This problem will only be exacerbated if you allow QA to add bugs into the current in progress sprint so your cycle will be :

S1: feature dev with some features tested.

S2: test remaining features and dev S1 reported bugs.

S3 : dev S2 reported bugs. final QA run through and sign off. Start next release branch features because theres not enough dev work left

A better approach is to have offset but equal length dev and test sprints and make them 1 week

S1 dev release 1 features

S2 test S1 features, dev release 2 features in new branch

S3 test release 2 features dev S2 reported bugs

Release 1 at end of S3

S4 dev S3 reported bugs

Release 2 at end of S4

If test have 'down time' they should use it to write the tests for the next set of features prior to development