Optimising the development flow in a Scrum team

Ministry of Testing

Case Study:

Any advice for optimizing the development flow in a Scrum team? There are currently ~10 devs (backend and frontend) and I'm the only tester so my workload is currently quite high. We're unfortunately doing a bit of a "mini-waterfall" right now, which means devs develop features during the sprint and assign the tickets to me to test them before deploying the feature on production (it's a web platform). Now as I'm the only tester, features may get stuck in testing for a while and devs pick new tickets in the meantime which results in even more stuff getting thrown at me. Features also usually include a few bugs which need to be fixed so they go back and forth between devs and me for a bit before they're finally ready for deployment. One thing I could do is making the devs test more, the question is how because they're not testing experts. We've started with unit testing but I still have to check the results there, not sure if they're testing enough or the right things. I think the biggest problem is really that I'm overloaded with so much work but hiring another tester is currently not possible. Anyone with similar experience and solutions for my problems.

-- Anonymous

Recommendation 1:

We used to do a 3 amigos/kick-off before any piece of work moved into an active state in dev. I used that as an opportunity to discuss the testing that needed to take place and would add notes covering what was discussed so that if I wasn't able to test it someone could follow my notes (and ask me questions if there were issues). It meant that the devs were more comfortable picking up tickets to test as they weren't coming at it cluelessly.

-- Anonymous

Recommendation 2:

Do the stories they are working on have acceptance criteria that they could at least do rudimentary testing around?

I was in the same boat at my last job - 2 dev teams of 4-5 devs each, just me testing. If things got backed up or I was out of the office, the devs would pick up testing of others' stories.

-- John Schultz

Case Study: Cont...

Yes, we even have Gherkin style scenarios as acceptance criteria, so that's pretty straight forward. I think the devs are currently not testing their feature after it's been deployed to our staging environment so that's one thing I want to make them do. We don't have any test cases currently, I'm more or less just testing every new feature manually before it's deployed. I want to get started with test automation to automate all these things but I really don't have the time at the moment... They don't really like the 3 amigos thing because the devs also don't have much time and they think it's a waste of time... Do you do the 3 amigos thing before the sprint starts or before someone starts working on a ticket in the sprint?

Recommendation:

Before someone starts working on a ticket that's been pulled into a sprint. The ticket is supposed to be reasonably solid before then as it will have gone through a refinement session with the team (done before they're pulled into the sprint), so the 3 amigos is about checking the story is still sound, that it's relevant, a quick discussion on whether the dev has any technical queries, and a quick discussion on the important test factors or any potential difficulties with testing. It's supposed to be a 5-10 min chat to make sure it's not going to be a waste of hours and to make sure everyone is working from the same assumptions.

All of these things can be time intensive in the beginning as the team learns how they work/what it means to them & their workflow but it does pay off. The speed of these things increases as people get more comfortable with the format & expectations.

I see 3 amigos as a time-saving exercise because it can help surface key info that people don't know they know or know they need. We did the 3 amigos round a screen at someone's desk and would often get other members of the team joining in because the work they had done in the previous ticket had valuable lessons - without the 3 amigos, it may have a been a day or so before that info was shared.

-- Anonymous