If you’ve done sports, you know how important rhythm and breathing are. In the fight it is very important to take your opponent’s breath away, and when running, you can’t take your breath away.
Planning the development of a software product, we set the rhythm, the breath of the team. Every 2 weeks (the length of our iteration) we are committed to release a new version of the product, which will move the customer forward, will bring him profit.
Simple rules apply when planning tasks. You cannot stretch/shorten the iteration. If all the iteration tasks are done, and 2 weeks are not over yet, you can do refactoring, pay your technical debts, or ask the customer to add tasks. If we made a mistake in our estimates and the planned tasks cannot be completed within 2 weeks, they should be postponed to the next planning.
The first situation occurs very rarely and is solved quite easily. On the other hand, the second situation happens quite often. To get out of a situation where planning was too optimistic, the easiest solution seems to be not to postpone tasks, but to finish them in a week and then plan the next iteration, so to speak, “without tails”. Here lies the root of the problems that arise after that. And after that, you get “breathless” as the team and the customer.
So, in 2 weeks we have 2 out of 8 cards left. And they are almost ready, but there was not enough time. The customer, seeing that only 2 cards are not made, suggests to finish them and agrees to approximate estimates (about 2-3 days for improvement). You can’t do this, because the remaining cards were wrongly evaluated from the very beginning. If you try to set a time limit for “reworking”, you can step on the same rake a second time.
Since these cards are still in place and the other 6 are made, it turns out that they were the last in the iteration priorities. To postpone planning means to deprive the customer of the possibility of assigning tasks to them. While the developers “finish” the last cards, they could plan new ones and start with the most priority tasks for the customer at the moment. Practice shows that the cards remaining from the previous iteration do not become the first in the next one.
During the “finishing” of the tasks, it is not clear who does what and when all this will end. What’s going on in your head can be depicted as this:
Chart 2: Time and Integral. In this case, it consists of team fatigue, number of accumulated errors in the project, customer satisfaction/dissatisfaction, etc. Simply put, the higher the curve, the worse things are with development. After each planning, the customer gets what he asked for 2 weeks ago, the developers are happy to show the finished work, so the relationship between the customer and the developers improves, becomes more trustworthy. Delaying planning leads at least to deterioration of the customer-team relationship.