We’ve written a number of posts about our decision to use agile development techniques in our marketing team at CANDDi, covering how we plan and review our performances. But what happens when tasks crop up that you haven’t planned for? Picture the scene:
You’re in the middle of a marketing sprint. It’s busy, but things are going well and your team is on track to deliver all of the committed work on time.
With only a few days remaining, your boss pulls you aside to share a brilliant idea he’s had for the next email marketing campaign. “It’s really important that we get this written up while the idea’s fresh,” he says, “so start work on it immediately”.
It takes you a day and a half to create the new campaign. By the end of the sprint, you have three important stories that are incomplete because you ran out of time. Two of them are as important –if not more so –than the new email marketing campaign.
If this sounds familiar, it might be time to consider how and when to say “no” to extra tasks during sprints.
Unplanned work during sprints
For developers, unplanned work in the middle of sprints usually takes the form of urgent bugs that arise with the software. Bugs don’t really come with a choice – if they’re significant, they simply must be dealt with as quickly as possible.
When unplanned work crops up in the middle of a marketing sprint, it’s usually because a manager has just thought of a new idea or strategy. It isn’t urgent in the same way that bugs are. Of course, it might seem urgent, but it’s up to the scrum team to decide whether it’s more important than the work it will displace in the current sprint.
The problem with unplanned work
The whole point of sprints is to learn from past iterations to make the future ones more productive. If your scrum team keeps making sprint plans informed by previous efforts only to throw these plans away for unplanned work, there can be no hope for progress.
How to say “no”
The best way to say “no” is to never actually say it at all. Refusing additional work isn’t about butting heads with your manager; it’s about ensuring everyone is on the same page about how much work can realistically be done in a single sprint.
This might be achieved by saying “okay, I can do that - but which of the current tasks in the sprint should we take out in order to make room for it?”. Or, you may decide that the unplanned work isn’t more important than your current tasks after all. When this happens, the unplanned task should simply be added to the backlog for future sprints.
It’s important that these decisions are the product of a conversation with the team. No one is better at estimating how much work can be done than the people doing it, which is why it’s the team who assigns story points during planning meetings.
If you find that urgent unplanned tasks regularly crop up in your sprints, it’s a good idea to begin accommodating this uncertainty into your sprint plans. Leave some room for extra work, or give one team member much less to do than everyone else so that they can dedicate time to unplanned tasks as and when they crop up.
How does your scrum team deal with unplanned work during sprints? We’d love to hear about it - get in touch!