I’m convinced that iterations are like jokes: the shortest are simply the best… Over the years, I had time to notice it. Therefore, in this blog post, we will explore together certain items that prove the relevance of sticking to realistic, short-term, and high-value objectives in order to produce deliverable increments more frequently.
Wishing to run a marathon
“Within one month, we already do not manage to achieve our objectives . . . Thus, in less than that, it is just impossible!” “We will never be able to finish our activities within two weeks!” “It’s been a year that we have two-week sprints, why change now?”
For those who tried to reduce their sprints or to promote shorter iterations must have faced quite a few objections.
Yep! it’s true; sprints’ duration depends on the market, its context, the expectations and availability of users, the Product Owner’s vision, and so on. However, there also are numerous factors related to the development team; for instance, its size, qualities (courage, transparency, commitment, respect), and experience.
It is not unusual, and it still puzzles me, to see teams learning to use Scrum to choose four-week sprints at the beginning of their projects or to maintain this operating mode. This decision is often made unjustly. That is, the choice is made based on a calendar rather than number of work days, on palpable resistance to disruptively change habits, on fear of awkward commitments…
Take a minute to recall the Agile Manifesto. The danger of opting for four-week sprints should be obvious.
Longer sprints provide comfort at the expense of efficiency (i.e. of delivery of value, quality, and improvements to the team). Let’s use the following comparison: a beginner or an occasional runner wishes to run a marathon or participate in an Ironman triathlon. Even if he is highly motivated, the results are unavoidable if his first attempts are too intense: he will not run the distance in the allotted time, thus he’ll rapidly become demoralized, come up against a brick wall and give up. Worst, maybe he’ll injure himself and compromise his physical condition.
What about you, do you have 4-week sprints? Yes? Why? Write down the reasons and let’s continue.
Conventional wisdom, causes, and remedy
Revisit the different reasons for having long sprints. Aren’t they insidious constraints, bottlenecks? Are they similar to the following reasons?
The client and users are rarely available for reviews and seldom communicate their needs.
Scenario: The client and stakeholders are rarely present during the presentation of the increments. They are located far from the development team or they rarely give their feedback. In fact, they lose interest in the product. In short, the team depends on the exchanges with the client, but the frequency is low.
Recommendation: It is unfounded to consider this impediment as an error of timing. It is obviously a communication problem, and the Product Owner and Scum Master are best suited to intervene. Revise the quality of your review sessions in order to ensure the participation of the stakeholders, client, and users. If required, get closer to certain new representatives who are using the product and who have an important share in its sponsoring, evolution requests . . . Is the location where the reviews take place appropriate? Have you considered teleconferencing as a last resort?
Furthermore, even though reviews are the perfect time to inspect what is done and determine the next steps, if there is no feedback, the Product Owner will decide the way to deliver value without considering time and based on a product backlog that is up to date, accessible, and ordered.
The client is intrusive and often requires information, new functions, and we comply with his requests.
Scenario: Contrary to the element above, stakeholders are completely invested in the project, so much that it becomes intrusive and hard for the team to manage. Changes during a sprint are frequent.
Recommendation: A sprint must not be too “elastic”. Change is welcome, but with moderation. If a change is accepted during an iteration, then we reasonably readjust work in all transparency, including with the client. We do not add one hour, then two, then four . . . simply to be reassuring today while we know that we’ll have to fix up the numbers tomorrow (not counting new integrations, releases, etc.). Remember that a sprint is based on an objective that has value in the eyes of the client. Thus, it must be preserved. The client must be aware of it and accept it.
There are too many changes? And they are all urgent? Why then wait at the end of the four weeks if it is not possible to make them during the current sprint? If you choose to have two-week sprints, then you’ll achieve two more modest objectives per monthly period. Furthermore, your sprints will be more malleable and you’ll be sure they will not compromise the current one! Ask the Product Owner to act as an arbiter and validate the requirements. It would be a pity for the requirements to cancel each other out or not to deliver value during the next weeks.
To minimize risks related to uncertainties regarding the client’s needs, whether technical or organizational, we give ourselves a certain amount of leeway.
Scenario: We are uncertain about the use of some technology or other. Our requirements need to be refined whereas we select them as sprint objectives. The members of the development team will not necessarily be available for the entire sprint, since they have to put out fires, to carry out other priority projects . . . The targeted tasks are so important that we mess up our estimates, we exceed them greatly.
Recommendation: It’s not a bad idea to allow for a buffer, but it has to be reasonable and controllable. Ideally, it should even be a time box. Also remember the principle of INVEST scenarios and SMART tasks and do not hesitate to use the mentioned criteria to solidify your sprints. If the selected items satisfy the criteria, then you know that your definition of “Done” is adequate. Based on this rule, you realize that you do not have enough items that are ready to be developed? Reduce your sprints’ duration and diagnose the problem with your team during the next retrospective!
Note about soliciting team members. To be efficient, a team has to dedicate 100% of their time to their project. If members of your team are requested elsewhere for an emergency (a real one, I insist!) or if the emergency happens at the end of a sprint, then you can more easily consider lending temporarily a developer without compromising the objective of the current sprint. Otherwise, let the team self-organize and focus on the project, and ask the Scrum Master to escalate the problem to management.
There are too many bugs to fix for the next deliverable.
Scenario: The number of bugs is high each and every iteration. The client is not satisfied and urgently requests patches. To meet his demand, we allow time for these requests. Therefore, we do need 4 weeks!
Recommendation: Isn’t a problem of accuracy of the definition of “Done” and of discipline regarding its application? Review your definition. Make it more precise and make sure everybody understands it. Then, communicate this definition to everyone taking part in the project, whether directly or indirectly. Display it publicly to get suggestions. Note that the criteria to assess if an activity of the team is “Done” must be measurable, reduced to the minimum, and strictly necessary. If it is not the case, it means that the criterion is not valid.
Before considering to choose long sprints to complete an item, first verify that your definition of “Done” is clear. Then, you will be sure that all team members will develop coherently, maybe not as fast, but surely. Not the contrary.
Most of the time, we do not achieve our objectives. If our sprints could be longer, we would appreciate it.
Scenario: We are way too optimistic during the planning sessions. We take too many items or the opinion of the team is not taken into account when defining the sprint’s objective and choosing its contents. As a result, to carry out everything, it takes a lot of time and we keep on having 4-week sprints . . . sometimes longer ones, but shush! it’s a secret.
Recommendation: According to Scrum, the objective is defined during the sprint planning session with the collaboration and agreement of the entire team based on their capacity. The Product Owner can make suggestions beforehand, based on his work on the product backlog. At the end of the first half of the planning session, the team has agreed on what they will deliver (i.e. the objective of the sprint and a sprint backlog to be groomed). The other half is used to decide how the team will organize themselves and to establish the list of tasks to be carried out. At the end of the planning, the team appropriates the sprint backlog, which contains SMART tasks. They also commit to respect the objective that could be revised, if necessary. In fact, the development team is the one who has the last word since they are executing the project. Given the team’s accountability and expertise, the decision they make must be listened to and respected.
A few more reasons…
If these arguments are not convincing you to take the step, here are less trivial but striking ones.
Acute “meetingitis” and loss of energy
Everybody is experiencing it or already experienced it . . . Meetings are time consuming and exhausting. If Scrum ceremonies are your pet peeves, know that with shorter sprints your endurance will be spared a little. Just ask around. Do you prefer having a series of meetings one after the other over two days for a monthly sprint or a maximum of two separate meetings of one day each? The second option is actually more appealing, isn’t it?
Furthermore, with shorter planning, review, and retrospective sessions, people’s concentration and energy are maintained.
It’s also a valid argument when people supposed to take part in these meetings are not coming because they are tired of endless meetings. Therefore, do not hesitate to play this card!
Experiment, there are no risks!
All in all, what do you risk? Do you still have objections? Does a risk come to your mind when being asked this question? The first time with a shorter sprint is admittedly clumsy. Experiment one or two sprints, and then analyze results objectively. Remember that it is not a permanent commitment. However, I’m sure that once you’ve tried holding shorter sprints, you will be surprised with the results and won’t be able to do without them!
Congratulations if you read this post from beginning to end! As you can tell, choosing the sprints’ duration is not a matter of time, of a team’s maturity level, or of a negotiation over quality. These factors should not be reasons for any team whatsoever.
No matter the team’s size or skills or the budget allocated to the project, the development of high-value deliverable increments depends on common sense, human values, and the team’s will to satisfy the client.
Train yourself and cultivate your champion spirit. Then, maybe you’ll be able to execute in one week only what you’d have expected to execute in four just a few months ago?