The ability of Agile teams to plan ahead and achieve their goals for a planned sprint differs widely. While some are able to conveniently achieve it without inducing many changes, others may fail to do so.
So what should Agile teams do to eliminate changes in their planned sprint?
To understand this, let's classify a planned sprint in three categories:
- Corporate work time: The time that goes into company meetings, general HR training, Scrum standups, etc.
- Actual Available time: The time the team actually has for working on project.
- Unanticipated Time: The time that is incurred by the team due to some unforeseen challenges inside/outside the project, the extra time taken by activities or some extra activities added to the project.
There is no hard and fast rule as to what proportions of the total sprint time should the above three categories ideally contain. While some projects allow a very precise foresight to decide a sprint time, others may not do so and the mere changing requirements of the project may lead to a disproportionately high unanticipated time.
While there is no such ideal time, as a Team Leader / Scrum Master, you can maintain a record of the percentage of unanticipated time over the total sprint period, and while planning your next sprint, do slight adjustments to this figure.
This process of planning works for teams that are interrupted moderately. But if your team is highly interrupt-driven, this unanticipated time simply shoots upwards, and in some cases it exceeds the actual available time.
How should you plan your sprints in such a scenario?
One of the most common solutions is that you adopt a higher period sprint. This is because, in a longer sprint, the fluctuations occurring on a small-scale are eventually washed out, and even if they are not, they make a negligible impact. The interruptions taken can be higher/lower than the previous sprint, but for the overall period, these interruptions do not cause the unanticipated time period to rise alarmingly.
Or you can simply adopt the exact reverse method. Plan very short duration sprints and live with the unpredictability. The drawback of this planning is that you will not be able to report efficiently, as there is very little certainty of your team achieving a milestone on a predetermined date.
Such interrupt-driven teams should plan sprints with light activity and few milestones. Unlike preplanning what need being done for months ahead, the team should decide in a short Scrum meeting what needs to be done in the next week and aim to achieve it. This allows you the freedom to plan and tackle contingencies as they come along, but as pointed out earlier, makes reporting to leadership more difficult.
Some interrupt-driven teams have also experimented with scenarios where a team member is completely devoted to taking care of the interruptions and unplanned work and addressing them. Based on their priority, he/she may tackle them as they come along, and ensure that the core team is fully devoted to achieving their milestones in the planned sprint.
What scenario have you used when working in an interrupt-driven Agile team? Please share as a Comment below or send us a tweet to @Intersog.
Featured image: journey-to-better.com
