Sprinting with bugs, or how to (not) create problems for yourself

In this article I will try to describe my vision of sprint planning, taking into account testing of sprint tasks and fixing bugs based on the results of testing. Suddenly, for me, the topic sparked a discussion on a project in which I am involved.

My name is Sultanov, and I am a team lead (heavy sigh). I try to make development predictable. Sometimes it even works out.

So, let's get down to business.

One fine day I’m working, not bothering anyone, and then the manager comes to me and says: “You’re eating a sandwich wrong, Uncle Fyodor!” “Your sprints are planned incorrectly. It is necessary that tasks leave the sprint already tested and with bugs fixed, otherwise we will not be able to close them!” And then he outlined everything schematically, something like this:

But wait, I answer the manager, because while testing is going on, the developer will either be idle, or take on another task, and he will have to be interrupted, or the third option – he will do the task until the end of the sprint, and fixing bugs will go to the next sprint, and that’s it wouldn't it be too great?

“I have 15 years of experience in development, and it’s always been this way, and so can you!” – the leader encouraged and disconnected. And I thought about it.

Essentially, the manager set me 3 conditions:

1. All sprint tasks must be completed within the sprint;

2. Development and testing should be in the same sprint;

3. All bugs must be fixed in the same sprint;

The conditions set immediately and strictly tie the processes of development, testing and bug fixing to each other. With this approach, when there is a direct dependence between the links, the work process will be constantly hectic. Usually they try to settle this with strong-willed decisions and strict demands from management to “better decompose tasks,” and this never works. And it will only work if the processes of development, testing and bug fixing are loosely connected.

Let me give you an example from another area.

Absolutely all more or less massive industrial processes have some kind of warehouses, reserves, funds. Every store and every production facility has a warehouse to ensure operational stability and decouple the supply of supplies from production and sales. If you try to work without a warehouse, then the goods on store shelves, raw materials in production will periodically (and quite suddenly) run out, and you won’t be able to create a stock – there is no warehouse. In such cases, any planning for future periods practically ceases to make sense, and the work of middle managers turns into constant overcoming of crises.

Let's go back to our rams features, and we’ll try to plan the sprint according to the conditions set by the manager.

Typically, when planning a sprint, the team lead (and his team, of course) is faced with one factor of uncertainty – the time it takes to complete tasks. Due to the team’s competencies, discussion and decomposition, and some time reserve in the sprint (we leave the developer a couple of days free), this factor of uncertainty is overcome, and the development process becomes predictable. More or less.

In the case of the presented boundary conditions, the number of uncertainty factors increases to three – this is the time for completing sprint tasks, the moment of transferring bugs to the developer (this is, of course, very unexpected, but testers also have blockages and they also get sick), and the time for working out the bugs themselves. At the same time, we can only preliminarily review and evaluate sprint tasks. Our sprint is standard – two weeks, that is, 10 working days, of which approximately a day (8 hours) is spent on mandatory meetings, rallies and agile rituals. That is, out of the 9 remaining days, I can plan work for only 4 days, and leave the rest for reserve and bugs, while I don’t even know whether these same bugs will come to the sprint. Well, or tell the developer “your mistakes – you can fix them in your free time”.

But, as our wise ancestors said, “if you criticize, make suggestions.” And the solution, in general, is on the surface. Don't try shove the unshoveable embrace the immensity, and use the sprint backlog to decouple processes from each other.

In other words, it is necessary to organize the process like this:

1. The developer takes tasks into a sprint and develops them, adding them to the testers’ backlog for the next sprint;

2. Testers routinely take tasks into their sprint and add bugs to the developers’ backlog;

3. Developers routinely take bugs with the highest priority into a sprint, and then sprint tasks and fixed bugs are put in a backlog for testers to check;

4. Testers check bug fixes and give their approval. The feature is ready.

We see that the full testing process takes 4 sprints, but everything is predictable, planned, evaluated and without crises that we create for ourselves.