Committed vs Completed

Everything below is a figment of my imagination, and mostly applies to the front end and mobile phones. Because I have very little Enterprise experience in anything else.

— Are you sure that you can do these tasks? – the manager asked his team, which included 4 developers (including me) and 2 testers, before starting a new sprint.

I hate questions like this addressed to a group of people. The manager seems to shift responsibility from himself to the team, saying that if you don’t do it, then it’s your own fault, I asked you… And how does he expect to receive an answer? Should we line up in order to answer? And then if the majority (like we have a democracy here, yeah) says “I’m sure,” then we’ll start the sprint, and if not, then… then what? Shall we remove a couple of problems like we did last time? But then, in the middle of the sprint, the developers became free and we added a few more tickets to the active sprint. At such moments, Jira even displays a warning: “Be careful! You are about to interfere with the sprint scoop!” (not like that, yes, I know, but similar: “Sprint scope will be affected by this action.”)

— Our team’s speed is 100sp, and we have already collected 150sp worth of tasks. Are you sure you'll have time for everything?

Repeated. Clearly he is shifting responsibility from himself.

…Two weeks have passed…

— So, the speed of our team is 100sp based on the statistics of several past sprints. All the time we take on tasks in a sprint whose amount exceeds our speed. And all the time at the end of the sprint we still have tasks that we promised to deliver, but did not finish working on them. Let's think about how we can make sure that we achieve everything we say at the beginning of the sprint? – the manager asked the team at the retro.

It would seem. Analyze the tasks that remain unfulfilled, draw your own conclusion, think with your own head about a possible solution to this problem… After all, you go to all our daily meetings! You know who was busy with what! You yourself saw how our 2-week sprint went… But no. Do all managers hate doing things with their own hands? Do all managers like to delegate?

I have already thought about this problem more than once. We will never be able to finish our sprint so that the brundown schedule ends up at zero. And I can't understand why the manager can't figure it out. I got into this project a long time ago, long before this manager joined us. I remember other leaders asking us these questions before… But you know what I can't remember? Don't get me wrong, I'm trying, desperately looking for memories, but I can't find them… Memories of how a manager at least once suggested a solution to this problem on his own.

– OK. I have proof that we will always see Committed > Completed at the end of the sprint. – I said. Oh, I'm sure of what I say. This rarely happens, I usually doubt it. But now, without any doubt, I am ready to present my explanations to the court… to the court of whom? A manager who doesn't deserve respect? No, to the judgment of colleagues. We are on equal terms with them, and therefore their opinion is very valuable.

– Always? – the manager asked with a grin.

He wasn't here a year ago, and two, and three. “Always?” – what does he want to say by this?! This problem has not been resolved for 4 years. And this is only in this project. I have had other projects with Agile and these graphs in jira. And it was all the same. Maybe I didn’t pay attention to it before because I was too young. Or maybe because he wasn’t afraid to change projects. “Always?” – as if he knows, as if he has seen other teams without these problems, but does not want to tell us about them. Like a kind dad who wants his child to find the right path on his own based on his mistakes.

– Always. I'll prove it.

Let's imagine that we have a team of 1 developer and 1 tester. A developer can do 6 sp in a sprint, and a tester can do 4 sp. We will have two-week sprints. Each task must be first done by the developer and then tested. Only after this the result can be given to the client. Let's say this is the first sprint of a project. Let's see how it goes.

1st sprint

The developer received two tasks of 5 sp (Dev 3 sp (this means that 3 story points are allocated for development in this task) + QA 2 sp (and 2 story points for testing)). Committed = 10 sp.

First Monday: The developer starts working on task 1.

End of the first Friday: the developer submitted task 1 for testing.

Second Monday: the developer starts working on task 2, the tester starts checking task 1.

End of the second Friday: the developer submitted task 2 for testing, the tester closed task 1.

At the end of the first sprint we have 1 unfinished issue: issue 2. It is ready, fully developed, but not yet tested. Team speed according to the chart in Jira: 5 sp (Committed SP = 10 sp, Completed SP = 5 sp).

2nd sprint

The developer received two tasks of 5 sp (Dev 3 sp + QA 2 sp), and we also have task 2 that needs to be tested. So, Committed = 15 sp (Task 2 (old) + Task 3 (new) + Task 4 (new)).

First Monday: developer starts working on task 3, tester starts checking task 2.

End of the first Friday: the developer submitted task 3 for testing, the tester closed task 2.

Second Monday: the developer starts working on task 4, the tester starts checking task 3.

End of the second Friday: the developer submitted task 4 for testing, the tester closed task 3.

At the end of the second sprint we have 1 unfinished issue: issue 4. Team velocity according to Jira chart: 10 sp (Designed SP = 15 sp, Completed SP = 10 sp).

nth sprint

Same as 2nd sprint.

This way we will always have Committed > Completed. That is, the tester will always not have time to test what the developer finished developing at the end of the week.

The only thing we can talk about here is how big the difference is between Committed and Completed. If we try to split a 5 sp task into two different 2.5 sp tasks and take 4 tasks into the sprint instead of two, we may get a different result. Let's see:

4 tasks of 2.5 sp (Dev 1.5 sp + QA 1 sp). If you do the calculations as in the example above, then at the end of the nth sprint you will get: Committed = 12.5 sp, Completed = 10 sp. We reduced the difference between Committed and Completed simply by using decomposition.

Then we can try to decompose even more: 8 problems of 1.25 sp (Dev 0.75 sp + QA 0.5 sp). In the nth sprint: Committed = 11.25 sp, Completed = 10 sp. I think you get the point.

Committed can never be equal to Completedbut it can get closer if we decompose our tasks very strongly.

— This happens because your processes are Waterfall wrapped in sprints. – the manager snapped. “All we need to do is ask developers to test their tasks.

Ask developers to test their tasks… I've heard that before. This is not just a small touch in our processes. This is a completely new process. Why do we need testers at all in this case? It is necessary for everyone to be “universal” in the team. And this is what we ourselves should have thought of and offered at the retro? Is it even possible to discuss such issues in retro? … Let's assume that he meant something else… Let's say he meant that developers just need to write more integration and automatic tests, performance tests. Wow, how will the cost of maintaining this goodness increase in this case? Our autotests already run for 4-5 hours. And these few tests are still written there. Why is it worth manually sorting out flaky falls in this heap of logs? The source code is almost 10 years old… I decomposed the technical debt into 3 person years, and this is only a superficial glance and a very rough estimate. Autotests need to be optimized because they were not written by developers, and there are simply hectares of opportunities for improvement. And we all know this, we’re just not given the resources to do it. We need to cut features. And if we suddenly decide to invest in expanding autotests and integration tests, then the development speed will drop very significantly. Doesn't he understand this?

— What if developers don’t want to do testing? – I asked, because I know that my colleagues will support me in this matter. No developer would want to do manual testing. Not because “this is not a lordly matter,” far from it. Because testers have their own processes, their own tools, their own metrics and approaches. You need to learn this, you need to spend time on it. And plus, what has long stood at the head of this division has not gone away: testers should destroy, and developers should build. Software is born out of this conflict. If we put this conflict in one head, then at best we will get a low-quality product, and at worst, destroyed motivation.

— Of course, the developers don’t want to test. We need to ask them to do what they do so well – write code. Write autotests! Yes, not everything can be automated, but what can be done must be automated. Then, at the end of the sprint, the developer will finish writing autotests, and the tester will finish testing manual tasks. Committed will be equal to Completed.

Yes, I expected this answer. I wanted to continue the discussion, but suddenly I thought: why is it even a problem that Committed is greater than Completed? We deliver features in the product sprint after sprint. We improve it, add something new. The team does not stand still. 100 sp per two weeks is actually an indicator. It can be used for planning. But why do we have to hand over everything we started the sprint with at the end of the sprint?

“Okay, let’s do it this way, you’re right,” I didn’t argue further. Because I realized that for the next 4 years in the project, managers will continue to ask the same question: “Why Committed > Completed in your sprints?”