Nobody likes surprises when they’re working on a big project… least of all, developers. But life happens and we understand that sometimes, clients need to make changes. Very often, those changes are voiced during the middle of a sprint. A client may want changes that affect a set of stories, tickets that are already in progress, or worse yet: tickets that have already been finished.
Mid-Sprint Changes: What’s the Big Deal?
Nobody hits the ground running with dev projects. There’s a lot of carefully planned prep work that goes on before the actual dev work begins. For example, for every sprint we perform, there’s a pre-sprint meeting in which we set up the story points for each ticket. We also map out the amount of time it will take us to work on each ticket.
So how much does it affect a project when we make middle-of-sprint changes?
Here are a few of the consequences:
- A new ticket. If the story has been deeply affected, the entire ticket may need to be re-done
- Longer testing times. Testing times will expand because testers will need to recreate test cases and/or modify existing ones, and then re-test
- Missed deadlines. The ticket may not be finished on time so a carryover for the next sprint is most likely to occur
- Changed metrics. The estimated story points for the ongoing sprint will also have an effect on the metrics
The Effect on the Development Team
So we know how mid-sprint changes will affect the metrics and the sprint itself, but how it will affect the team that’s working for this client? Any given team can consist of testers, developers, a business analyst, and more.
Usually, when changes are too big to be made during the middle of a sprint, the team doesn’t always take it well. The main reason is that they feel that everything they’ve done up until that moment has been a waste of energy. That can be a real morale-buster.
Here are some other team factors to consider:
- Technical skills (if a change gets really complicated the developers may need an extra hand to work with)
- Research in order to apply changes required
- The number of tickets that have been worked on by a particular developer
- Business analyst also needs to recreate the story according to new changes
- Testers will need to edit test cases that have already been created. Then, they’ll need to test the story once again, in order to ensure it matches the functionality of the changes
When Making Mid-Sprint Changes is a Good Idea
Ask any development team: mid-sprint changes are nothing new. We handle them and move on. But the problem really begins when the changes are incredibly complex and there’s a lot of work to be done and it’s no small matter to make those changes. The question becomes: how do we proceed?
Sometimes, we’ll make those changes anyway. We thrive on long-term working relationships with clients so the decisions we make during the ‘honeymoon period’ can really matter. Plus, making those complex changes might make the difference as to whether we actually keep a client, whether they’re new or old.
Whatever the case may be however, we also know that many times, last minute changes just cannot be done. Knowing this, how do we proceed?
Deciding Whether to Make Changes: It’s a Process
As with everything we do, deciding whether to make mid-sprint changes is a group effort.
First of all, an internal meeting is needed to evaluate the changes. The team needs to discuss how to proceed and how it will affect both the project and the team.
If it’s not possible to complete the changes, the ongoing sprint tech leads and the PM of the project will need to have a meeting with the client to redefine expectations.
Does this mean that sometimes we actually need to say ‘no’ to the client?
YES, it does. When a client keeps making changes not only during the middle of a sprint but also at the end, they should be informed about the impact these proposed changes will have on their project. If nobody informs them, then most likely they will keep on making changes. Always saying ‘yes’ can result in compromises or not being able to finish on time.
How to Say ‘No’ to a Client
So here is actually where it gets difficult. We know that saying ‘no’ to a client when they want to make a change is no easy task. Unfortunately, however, sometimes there’s just no choice. When that happens, we need to be careful how we break the news. The best way to do this is by providing the client with the exact reasons why we can’t accommodate their changes. It always helps when they understand why.
As I mentioned before, this is not an easy or pleasant task to perform. Tech leads and the PM will need to be the ones giving the necessary explanations. To help them out, the entire team needs to provide them with the valid reasons why they cannot accept each specific change. That helps the tech leads and the PM prove their point to the client and helps the client understand the consequences of the request.
Communication is Key
In my personal experience, I´ve worked on a lot of different projects, sometimes as a tester and other times as a tech lead for my area. When the time comes and we need to say ‘no’ to a request and we’re not going to be able to perform the task in time, providing the valid reasons why the request is not possible always proves useful.
I can say that in almost every case, the client will understand why the desired task cannot be completed and they will agree to move it to the next sprint, maybe divide the story into two separate stories or even move it to the next iteration.
So bottom line, don’t be afraid to sometimes say ‘no’ to a client. With valid reasons that are communicated clearly and with respect, they will understand.