At Software Planet Group, we pride ourselves on our extremely efficient development process, which includes software outsourcing as an integral part of our operations. However, from time to time, the old faithful must make way for disruption.
What is a Sprint in Agile development?
For those of you who are not yet familiar with Scrum, In Agile methodologies, a Sprint is a time-boxed iteration that serves as the backbone for delivering incremental value to stakeholders. Typically lasting between one to four weeks, each Sprint commences with a planning session where the team collaborates to prioritise and estimate user stories. These stories are then pulled from the product backlog to form the Sprint backlog, establishing the scope of work for the iteration.
As the team progresses through the Sprint, they develop, test, and refine the chosen features to ensure a high-quality, functional deliverable. The Sprint concludes with a demo, where the team presents the completed features to stakeholders, effectively showcasing the incremental value delivered.
Finally, a retrospective meeting is held to reflect on the Sprint’s successes and challenges, fostering a culture of continuous improvement that helps the team evolve and adapt in their Agile journey.
Unplanned work in the Scrum methodology
But where then does the disruption originate from? Well, it’s complicated, you see…
What happens during Sprint planning
At the start of development, the very first thing we must do is define our Sprint goal. This spells out the main objective that for the duration of the current Sprint the development team will be striving towards achieving. In order to define it, the customers are invited to a so-called Sprint planning meeting, where team members can then discuss the project’s iterative scope. Driven by their business priorities, complexity, dependencies on other tasks, and the efforts required for implementation, user stories from the backlog are moved into a Sprint plan. The most essential of these is then defined as the Sprint goal.
So far, so good, but things don’t always stay that way!
Reasons for disruption
Perhaps at the appropriate time, the product owner was too busy to refine his or her requirements, and as a result, felt the need to chime in with changes in the middle of the current Sprint; or maybe these modifications are now being wedged in edgeways in a sudden attempt to maximise their company’s return on investment; perhaps even it was all due to an exciting business opportunity that compelled the product owner to make haste to impress their clients.
Whatever the reason may be, however, any ill-timed alterations will all but certainly hamper development. Introducing changes into the scope mid-Sprint can be disruptive, it can lead to a loss of focus for the development team, as they may have to shift their attention away from the previously agreed-upon Sprint goal. This sudden change in direction can also result in decreased productivity and efficiency.
Changes have different effect
Not all changes are equally disruptive. If it is a matter of exchanging one user story (US) in the Sprint plan for another from the backlog, where the new US is known to the team and takes roughly the same amount of time, such a “trade” should be relatively easy to handle. Anything more significant and uncertain may cause damage.
The likely fallout
Demotivated developers
A wise man once said that every good team is like an expensive pocket watch. Should you choose to tamper with its delicate internal workings, whether or not your intentions were noble, you would likely still find yourself with a defective piece of junk — or, to state it in another way, if it ain’t broke, don’t fix it!
Though the skills and abilities of individual developers will of course remain unchanged by any external abrupt interventions, by constantly making them shift gears in the middle of a complex project, you disrupt your team’s momentum and compromise their group morale. Changing the scope during a Sprint can undermine the team’s confidence in their planning and prioritisation process, leading to uncertainty. It can also create a sense of instability for stakeholders, who may begin to doubt the team’s ability to deliver consistent, high-quality results.
Undermined Sprint plans
As hinted at above, in the Agile methodology, we need an element of predictability to guarantee developmental stability, in addition to team performance. With the help of software metrics, for instance, we can pinpoint our team velocity and find out how many Sprints are left (e.g. our velocity may indicate that the project will take 10 Sprints to complete, so if we’re currently on the third iteration, we can reasonably assume that we’ll be finished in seven Sprints).
This may lead to broken promises and inability to fulfil the Sprint Goal.
Frustrated customers
As a knock-on effect, making sudden, unexpected changes may also frustrate the customer himself, as it will weaken the team’s ability to adhere to the project roadmap and make it difficult to gauge and communicate the total impact of the added demands.
Managing Unplanned Work (the Software Planet way)
For all these reasons, when dealing with unplanned work in Scrum, we believe it is essential to have a feasible game plan in place:
1.Never change plans in the middle of a Sprint
The Agile manifesto seeks to prioritise “individuals and interactions over processes and tools.” This is why, despite anything to the contrary, we do allow our customers to make changes as they see fit, but we do this in a sensible way, by adapting the project as needed — and “the sensible way” in this case is to keep our Sprints sacrosanct!
2.Work with shorter iterations
As a perk of the versatile Scrum approach, we are able to freeze requirements within Sprints of predetermined lengths. In this way, if the client is partial to opining at shorter intervals than is normally needed, we can take the preemptive action of equally shortening the Sprint. We do this, however, with Sprint planning and demo meetings in mind.
3.Start again if necessary
If, for whatever reason, we are prevented from following through on the important steps outlined above, this is when it will become necessary to terminate the current Sprint and refashion the iteration from scratch — thankfully, however, this only ever occurs on particularly rare occasions, as we make good use of continuous feedback to keep all parties informed at all times.
So how can Sprint planning be effective?
Though having to handle unplanned work is undoubtedly a challenging beast, at SPG, we believe that paying attention to these simple Agile best practices is enough to save both customers and developers from the ensuing hell.
