Get a Customized Plan

The Fairway Technologies Blog

Useful Tips for Sprint Snafus: Part 2

In IT management, sprint No Comments
July 31, 2019

In the second of a two-part blog series, Michael will talk about how to deal with mid-sprint corrections. Previously in Part 1, Michael discussed useful tips for avoiding issues early in the sprint process. So, join Fairway Technologies’ General Manager Michael Krasowski for a few noteworthy sprint insights for managing an IT team.

Whatever Can Go Wrong – Will Go Wrong

Murphy’s Law is a popular saying that states that "things will go wrong in any given situation if you give them a chance," or more commonly, "whatever can go wrong, will go wrong." Whether you are planning your sprint or are in the middle of your sprint, you should expect things to go wrong from time to time. And that is just fine. In my last blog article, I discussed “defensive sprint planning” and provided ideas on how to avoid problems before they happen. This blog article is centered around issues that may arise “mid sprint” and how you might deal with them.

Discovering Unexpected Problems

Now that we established that you WILL have problems, how might you do things to minimize a potential dumpster fire? By discovering unexpected problems as early as possible. Therefore, consider working on the hardest, most uncertain tasks early in the sprint, or just do them first no matter what. This will help you find the tough problems sooner and you will have more time to fix them or get the help you need. Share issues that may arise with your team ASAP or at least by the next stand up. This will give an opportunity for all team members to help collectively solve issues or remove blockers. Now, let’s see how we cope with challenges once we find them.

group-of-young-programmers-developing-data-code-TJ9VUCP

Dealing with Unexpected Problems

Here are some options for dealing with unexpected problems. With small setbacks, absorb them into the sprint by using Slack. Slack is time earmarked within an iteration or sprint that will be used for unanticipated activities. Basically, you are setting aside time for unexpected problems. Slack gives your team wiggle room in each sprint. If the number of story points in your sprint is identical to the velocity, you are likely overcommitting your team (not good) and at the same time not allowing for any Slack time (also not good). I recommend setting aside Slack time in each sprint. Maybe you target your story points at 90% of your velocity allowing for 10% of your velocity for Slack. You will figure out the right amount with your team over time.

Also, consider reducing non-critical refactoring. That technical debt you were going to work on? Well, put it aside for now and focus on the issue at hand. Another option is to cancel a spike—that is, if you have a planned spike task. A spike is a controlled experiment to provide information and hopefully clarify any technical issues by setting aside the complexities of the production code. When you need to prove a method or approach, a spike is a great way to get additional information by developing small, isolated experiments. But, spikes are certainly candidates to cancel if your team is stretched too thin. The story point allocated for the spike can then be replaced with solving the issues at hand.

Or, each member of your team could work an extra hour or two and make up the lost time solving the issue. This can be a slippery slope and affect morale. Discuss possible strategies during your standups to get a reading on the team and how they may want to approach working those extra hours. Don’t make this a habit.

So, You Have Even Bigger Problems?

If some issues are just too big to absorb—whether in Slack, as a replacement for a spike, or through having your team work a few extra hours—then it is time to replan. First, acknowledge as a team that life happens, and things can be more complicated than expected. Then, call a meeting with the full dev team and the product owner since the replanning may affect the outcome of the sprint or even the release. I might suggest a preliminary meeting without the product owner to sort things out and come up with some options. But never choose to reduce scope without involving the product owner.

First, consider reducing the scope of the story in question. This is a good approach since the product owner will at least get some functionality delivered. So, take that user story and decompose it into two or three smaller stories, and commit to only one of those, instead of all of them. Or you can remove scope, that is, remove the user story that is causing the issue completely from the sprint. You can readdress this story in the sprint review or at the next sprint planning meeting. This is not unusual, so don’t be alarmed. Again, it may be caused by complex business rules or technical challenges that the team was not aware of.

programmers-working-in-software-developing-JWUKZXP

Guidelines for Handling Mid-Sprint Issues

Any sprint that delivers user stories, even if you had to reduce or remove some stories from your plan, is a successful sprint. Don’t think otherwise. Yes, your velocity may go down but that is not necessarily negative. We always want the velocity to reflect the reality of what your team can produce. If your velocity trends lower, then what you take on with the next sprint will be lower as well.

Never change the iteration deadline. Remember we are timeboxed, not scopeboxed. Scopeboxed means we can stretch out the time to accommodate a fixed scope. This is not the cadence you want and compromises the benefits of the iteration or sprint. Stick to the these timeboxed sprint guidelines:

  • Features are planned but undetermined—which means the scope may change and not every story may be completed by the end of the sprint.
  • The date is certain, meaning the date does not move. Sprints always end on time.

Dealing with Partially Done Work

Now let’s talk about how we deal with partially done work at the end of a sprint. Normally, at the end of a sprint every story demonstrated should be completed. Or another way of saying it is that only completed stories will be in the build and shown in the demonstration to the product owner. But, at times, not all stories will be 100% complete. These are known as partially completed stories and should not be in the build or the demo, and not counted at all towards the velocity.

Partially completed stories should be rare and for the reasons we discussed earlier. But, if you have partially completed stories, what do you do with the code? One option would be to delete the code for unfinished stories and deliver only what is done. You might be deleting code, but you are not deleting what you learned, and that knowledge will stay with the team for the next sprint. If you don’t delete (remove) the code, over time it could become technical debt that will cause more trouble downstream. It could be that the product owner’s priorities may change and maybe you won’t get back to this user story for quite some time thus leading to technical debt.

Another option may be to leave partially completed stories in the code base if (and only if) you are going to work on it in the very next sprint. That will work. But if you are not sure when, if at all, you may work on it, it is best to just remove the partially completed feature from the code base.

Handling a Lost Sprint

Sometimes, life happens, and you realize mid-sprint you will have nothing to demonstrate to the product owner. Yes, that is a bummer indeed. But if that happens then the sprint is declared a “lost sprint.” So, what do you do when your world comes crashing down? Here are some options:

  • Inform your product owner immediately. Ensure they know exactly why the sprint is lost and prepare for a longer than normal upcoming sprint planning meeting. In that meeting, discuss the issues and plan your next sprint accordingly. This could be an uncomfortable meeting so be prepared and do your homework with the rationale for your recommendations and options.
  • Decide whether you should roll back the code or just leave it in your source control library since you may be working on the same code in the next sprint. But again, be cautious and don’t let this code become technical debt.
  • Use your last velocity moving forward, not the velocity of this sprint since it is dead on arrival and would effectively be zero. Do not use this sprint’s velocity of zero in your sprint averages either since it would skew things. That is my opinion, but others may say put the zero in the mix.
  • Focus your sprint review and retrospective with your dev team on what happened and how you will move forward. Provide a safe and supportive environment, if you can, so you can get to the root problems and the team can share their ideas and actions moving forward. This will more than likely be a much longer sprint review.

Lost sprints should only happen rarely. If it happens more than you think it should, then something is wrong—maybe very seriously wrong. Seek out other agile and sprint experts in your company or maybe external consulting firms and see if they can help you figure it out.

The Bottom Line

Since we have all experienced how things go wrong when you least expect it, try and discover unexpected problems as early as possible in the sprint. Consider working on the hardest, most uncertain tasks early in the sprint. I would rather know my pain points earlier rather than later.

For smaller unexpected issues, consider using your Slack, spikes, and (if you have to) overtime to meet those needs. Having Slack planned in your sprint is always wise and I think should be a regular item in your sprint backlog since spikes may not be in your backlog very often. Overtime work can affect morale and cause a “false positive” in your velocity and should be your last resort.

If those options won’t work because you have really big issues at hand, consider reducing the scope of the story in question. This is a good approach, since the product owner will at least get some functionality delivered by decomposing the story into two or three smaller stories and just committing to one of those and not all of those. Or, remove scope completely from the sprint. You can readdress this story in the sprint review or the next sprint planning meeting.

Here is a great quote to wrap up this article: “Do not try to make circumstances fit your plans. Make plans to fit the circumstances.” by General George S. Patton. He would have been a remarkable scrum master. Circumstances will change, business is dynamic, plans will need to be altered, updated, and sometimes even scrapped. Be open and prepared for that inevitability.

If you missed my last blog article, check out Useful Tips for Sprint Snafus: Part 1.

Want to Learn More?

If you want to learn more about developing effective agile sprint plans, please check out one of my Pluralsight courses: Developing Effective Agile Sprint Plans by Michael Krasowski. URL: https://www.pluralsight.com/courses/developing-effective-agile-sprint-plans.

Screen Shot 2019-07-30 at 1.56.25 PM

Michael Krasowski

General Manager

Fairway Technologies Inc.

mkrasowski@fairwaytech.com

New Call-to-action
New Call-to-action