We’ve covered what the Agile method consists of in software development, your role as a project manager using Agile, and what to do in each sprint. However, your role means you have to be prepared for any situation. Here are a few situations that may come up, and tips for how to handle each one without putting the project or your team in jeopardy.

Tip #1: Don’t bring an unspecified item into the sprint

If a backlog item has unclear or incomplete requirements, it should not be included in the sprint. If you put an ambiguous task in the sprint, then your team runs the risk of incorrectly implementing the feature or disrupting their sprint schedule, because it may have been estimated wrong.

You as the project manager should work with the client, design, and engineering to make sure that all priority items are fully specified prior to the sprint planning meeting. 3–4 days before starting a new sprint, make sure the highest priority items are well documented and discussed. Reach out to the product owner and clarify an item before the sprint starts and your team begins the sprint planning.

Tip #2: Don’t change a sprint’s priorities once it starts

Once a sprint starts, the team cannot change the focus of the sprint. If the client approaches the team with a request, then you can add that request to the backlog and revisit it during the next sprint planning meeting.

Changing priorities mid-sprint disrupts the focus of the team and undermines the integrity of the sprint. Just as the team commits to delivering their planned items for the sprint, the product owner must commit to not interfering with the sprint once it starts. Make sure you manage both of those commitments as the PM on the project.

Tip #3: If a technical emergency comes up, cancel the current sprint

There will be moments when the client demands your team immediately looks into a critical item. In these cases, you can work with the client to accommodate their product needs as quickly as possible. But, you should cancel the current sprint so your team isn’t forced to deliver the sprint objectives according to its previous timeline.

Once the emergency item is resolved, you should lead an ad-hoc retrospective meeting to conduct a root-source analysis, asking questions like?

• Why did this issue happen?
• Why did that happen?
• And why did that happen? etc.

Then, make recommendations so that a similar problem doesn’t happen again. Finally, you can regroup with your team to schedule a new sprint on an irregular calendar schedule.

Tip #4: Below-the-line items are okay!

Developers on your team might prefer to err on the side of conservative estimates when it comes to their tasks, but sometimes they’ll tell you they’ll probably have extra time during any given sprint. In these cases, you should draw “below the line” priorities for each sprint.

Basically, “above the line” tasks are sprint items that your team is committed to delivering by the end of the sprint. “Below the line” tasks or “floating items” are lower-priority items that they will work on if he or she has extra time but aren’t obligated to deliver or even start working on during the current sprint.

By having these below-the-line items defined, you can make sure priorities are completed first but also be ready to take advantage of your team’s extra time to get a few more tasks done for your client.

Tip #5: Don’t include clients in the daily standups

It’s not a good idea for clients to join daily standup meetings. The daily standup should be a safe space where all individual contributors can honestly share the status of their work and ask for help as necessary. There’s many reasons why a client may hinder this:

• If a client is there during a daily standup, your team may not want to look bad in front of the client by admitting to a problem or a delay.
• Your team also might not share the same native language as the client. Having to speak in a foreign language could cause them to miscommunicate or refrain from speaking; speaking in their own language would come more naturally to them and allow them to speak openly.
• Clients will be frequently tempted to add new non-emergency items to the sprint during a standup, which will slow down your team and disrupt all the work you’ve done as a PM.

Tip #6: Never surprise the client with a failed delivery

You should keep an eye on the progress throughout the sprint. If you notice that there’s a risk of slippage, check in with the team to get an understanding of what’s happening. Then, reach out to the client to inform them.

The client should know if the team had unforeseen issues or unknown spikes were required. It’s always better to keep the client in the loop rather than “surprising” them at the end of the sprint with a failed delivery. They might want to deprioritize an item over another; it also keeps communication open and honest.

Tip #7: Do a weekly bug status report

Every week, it’s a good idea to put together a bug status report for the project. This report can track the number of bugs left in the backlog and also tell you how much bug fixing your team has done vs feature implementation. This data can bring clarity to the client, showing why a developer had a “red week” spent fixing bugs and didn’t prioritize working on features (which, hopefully, was what the client requested).

With these tips, your next sprint will be even more successful: your team will fulfil their commitments better, and your client will stay informed and happy with your and your team’s work.

‍