Solving the Scrum Deadline Debate

When software companies are working within Scrum, deadlines can often create stressful and contentious relationships between product development teams and their senior management.

I regularly witness Scrum teams and senior management hitting deadline roadblocks or missing them altogether. Usually, miscommunication or a failure to recognize and adapt to changing conditions are the culprits, but there are several other missteps that can cause friction.

Here are some of the more common issues I’ve noticed:

1. Scrum teams believe that because they are agile and often committing to four week (or shorter) sprints, they cannot commit to longer term deadlines.
2. Management teams, on the other hand, want Scrum teams to agree to exact release dates over a 12 month period.
3. Failing to see eye-to-eye already, management teams insist on quarterly deadlines for their Scrum teams.
4. The Scrum teams may eventually agree to those quarterly deadlines, but if the right processes aren’t in place or the deadline wasn’t realistic to begin with, the Scrum teams miss their quarterly deadlines for the rest of the year.

I recommend a completely different approach. It takes into account variables like a Scrum team’s known velocity and applies a more collaborative approach between management and product development.  Known velocity is necessary for any true commitment and it helps clear up any disconnect between Scrum teams and management.

Here are some things to consider when establishing deadlines:

Establish Historical Performance

It can be difficult to establish realistic deadlines without better understanding a Scrum team’s productivity and historical capacity. With that in mind, the Scrum team needs to land several sprints in a row to determine what its stable velocity is.

Medium and long term commitments can’t be made until that velocity is established. Once it is, management teams will have a clearer understanding of how to plan for product release and completion deadlines. But you don’t have to remain stagnant while that velocity is established. In the mean time, product management should provide a road map and ready backlog that will plan for future based on what it knows today.

Use Backlog Estimates to Plan Release Dates

Once the Scrum team knows its velocity and has developed comfort with its reference stories and estimates, the team should plan to break down the current backlog and estimate it. That can take time depending on how far into the future the backlog goes and how ready it is for estimation, but the wait is worth it.

With that work complete, release dates can then be estimated by dividing the team’s proven velocity into the total backlog estimate.

From there, teams should be able to plan a release date. Make sure you still provide a buffer for that deadline, though. Over time, the team’s ability to estimate accurately can be monitored and improved, but some tweaking may still be necessary on the first few tries.

Continually Update the Backlog

There will undoubtedly be changes to the backlog and those changes may have an impact on the established release date. Teams should update the backlog estimates continually, which will allow the manager to make better decisions based on the impact it could have on release dates.

If change is necessary, managers should modify release dates based on the backlog changes and take into consideration any related effects they could have on the Scrum team’s velocity.

A Major Caveat

Velocity can sometimes mislead, and yesterday’s performance can be a very poor predictor of today’s and tomorrow’s performance.  The following items need to be taken into account:

• Velocity and story point estimates are only as good as the team planning sessions and accuracy, and detail level, of the stories
• For meaningful velocity measurement, it is absolutely essential to have:
  • A broad set of sized reference stories that the team feels good about and that represent the scope of work in the backlog
  • A global definition of done that has the explicit agreement of every developer and product stakeholders (including senior management)
  • Significant product direction changes, shifts to new levels of technical complexity, new technologies, innovative functionality, significant UI changes, significant architecture changes can all make historical velocity meaningless, so planning needs to become more conservative for significant changes
  • Changes to the team, including loss of people, new members, new management, new ScrumMasters, all impact velocity.

If you need to make a decision today

Taking steps like the ones I laid out above take time and not all management teams have the luxury of waiting. In that case, those managers need to prioritize and decide exactly what each commitment needs.

Instead of focusing on entire product releases, management teams should consider identifying a few features that its sales and marketing departments absolutely need. From there, management can ask the Scrum team to estimate a deadline for those features and deliver them as accurately as possible.