Managing the sprint
We all run into at least a few common challenges when managing sprints. The good news is that making a few changes can have a really positive impact and help your sprints run smoothly.
So far, the beginning of this year has been about getting back to basics. Last week, I reviewed the backlog planning process, so it seems natural that this week, we review some common pitfalls in what happens next: the sprint.
During the sprint, your engineers pull tasks from the sprint backlog to work on. As they do the work, they might have further questions about it. Design work may still be required, and disagreements or challenges may arise.
Have you been in this scenario? The sprint ends, and your QA team starts testing everything before the push to production. Several features are ready, but a priority zero bug has been found in one. Fixing it is expected to take at least a day, but the engineer who developed it is on vacation until next week. The next sprint has already started. Disconnecting the feature is complicated as it affects many parts of the application. The entire release is now delayed since you can’t have users experiencing this bug. The engineering team can work on it, but it may take three times longer. It’s better to wait for the developer’s return.
You’ve probably seen this happen before. Several things are going wrong in the situation above, but they can usually be solved with a few process changes:
QA is happening too late in the process.
Solution: QA earlier, as work is being finished. Involve engineers in the process. Finish development work a day or two early to allow time for everyone to bug hunt and put the polish on the release.
Your team is dependent on a single engineer/developer.
Solution: Cross-train, pair program, or whatever it takes for others to become more familiar with what their team is working on.
If one thing is broken, nothing can be released.
Solution: Leverage feature flags, and do your best to plan features so that they can be enabled or turned off independently. This would also benefit you by enabling the roll-out of features to a set of BETA testers for real-world feedback and testing before going live with all users.
Some common sprint problems and how to avoid them:
The QA team is a sprint behind your engineering team.
This happens when QA is left until the end of the sprint. Your QA team should write automated tests where possible and be testing work as developers finish it. You might need more QA testers, or you may need to take on less work each sprint to improve quality and reduce bugs.
Many stories are staying open for an entire sprint.
It’s likely your stories are too big. Leverage concepts like the smallest functional slice and push for better estimations during sprint planning.
Engineering only gets half of their work finished.
A few things could contribute to this: either they were severely oversubscribed, estimates were off, some blocker was preventing them from getting work done, or there was a lot of unplanned work that happened. You need to get visibility into the work and narrow down the possible causes. It's time for a retro!
Nothing is ready for release, and everything is half-done.
This could be a sign of too much work in progress. Ideally, engineers are finishing one task before moving on to the next. The opposite can happen for a variety of reasons:
Engineering gets blocked on a story
Stories are not standalone pieces of work and have multiple non-linear dependencies.
You can resolve this by adjusting the scope to meet the sprint goal, breaking stories up into vertical slices instead of horizontal ones with many dependencies, and adding a work-in-progress limiter to your project management software to help flag the issue earlier.
The last sprint’s work was buggy, and now you’re spending this sprint fixing bugs.
This can happen when all the testing is left until the very end of the sprint. You can help alleviate this by doing QA on work as it’s finished, writing automated E2E and unit tests, and having developers review each other’s work.
There are missing features or capabilities despite stories being marked complete.
Take a moment to review the acceptance criteria for that work. Are they clear? You may need to be more specific, include more detailed designs, or spend more time talking with engineering about the work while having more of an open feedback loop.
Engineering is blocked by design.
Spikes and design tasks a sprint or two ahead of time can help alleviate the design bottleneck. Ideally, you’re coming into the sprint with a detailed plan for doing the work already committed.
You feel like there’s no visibility into progress until the end of the sprint.
A mid-sprint review meeting can be a helpful pre-demo meeting to review the work completed up to that point. It can also be an excellent opportunity for feedback, course correction, and cutting scope to meet deadlines.
If your teams are struggling with some of the above, feeling overwhelmed, and genuinely feeling like they can’t get caught up enough to solve any of these challenges, then it might be time to have a cooldown sprint. Instead of assigning new feature work, everyone should work on getting caught up on bugs, fixing the technical debt, building QA automation and getting caught up.
Remember, you’re not alone in solving these problems. Work with your team to help narrow down the issues and refine your process. Sprint retros can be a constructive way to get alignment and drive solutions. Follow my 7 steps to a good retro to ensure you get the most value.
What other common challenges do you see teams struggling with? Do you have a unique situation that might call for an even more drastic approach? Reach out for some one-on-one coaching for a tailored solution for you and your team.