Minimising the impact of Sprint disruptions


blockinganattackOne of the biggest challenges we’ve faced is trying to balance project work or product development with business-as-usual (BAU) work that can’t necessarily be anticipated – how do you manage the risk of disruption?

One of the main points of Agile is maximising output/value in a dynamic working environment. Achieving the highest possible return for a given investment. The problem is that a lot of companies don’t have the luxury of separating project teams from BAU teams – they are the same team. This added complexity can, if not managed correctly, result in reduced efficiency, reduced output and reduced value.

So, how do you make sure to deliver your sprint goals when high-priority requirements are coming in from left-wing on an ad-hoc basis?

One good way to handle this is to look back over previous sprints to get a sense of how much time was spent handling BAU.

If there is a trend e.g. you’re consistently replacing 20% of your sprint with BAU, then your velocity should be rather reliable – you’d just go ahead and consistently under commit by 20%.

If there’s no trend then try to get a sense of the average amount of disruption or (or track Standard Deviation across sprint commitments vs. actual velocity).  If you calculate the value of this disruption using Story Points, you can then commit this value of points to Stretch Tasks and burn up on them – explained in my other post about managing sprints alongside BAU.  This approach will also give you a better idea of the team’s actual velocity, which will help you to plan more accurately going forward.

In any case, if the disruption doesn’t occur then the team is able to work on the highest priority tasks outside of their original commitments. If the disruption does occur then you’ve planned for it.

Happy days. :)

Subscribe to the Agile101 RSS to be notified when I upload new Articles, Videos, Templates and Tips!

Related articles:

  • Managing sprints alongside BAU (agile101)
Share this!
  • Print
  • PDF
  • del.icio.us
  • Digg
  • DZone
  • Reddit
  • Technorati
  • StumbleUpon

4 Responses to “Minimising the impact of Sprint disruptions”

  1. Rod Claar says:
    July 10, 2009 at 9:25 pm

    Good thoughts. The other way to handle this problem is to “short” your capacity, or in other words, just commit to less. When the disruptions are occasional and unpredictable it can also work to just drop stories off the sprint backlog when something comes up. However I tend use your approach. This way there are stories with trackable sizes that help you plan in the future.

    Rod Claar

  2. taraleewhitaker says:
    July 11, 2009 at 12:56 am

    Thanks for the words of encouragement, Rod. :) I’ve amended the text to emphasise the ‘shorting’ option. It’s definitely better to under commit and deliver what you say you will.

    On a side note, I suppose the other benefit of estimating scope creep/BAU and counting it as part of your velocity is that you get a better sense of the team’s actual capacity/output and how they progress and/or improve over time – e.g. are they becoming more efficient and effective as a team or are they simply being less disrupted.

  3. Alan Dayley says:
    July 16, 2009 at 10:07 pm

    You describe good tools for including disruptions in planning. Thank you.

    We have used one estimation method that has helped, but also has a downside. We use “ideal days” for estimation and define it as six productive hours. The other two hours of a typical eight hour work day are used up in breaks, hallway discussions and interruptions from other unplanned things. This seems to be reasonable.

    The downside is that this hides up to 10 hours of interruption per week, per developer. That is a lot of time lost. It also defines an moderately interruptive environment as acceptable. In other words, it’s a way of hiding a problem that could be hurting productivity more than we know.

    Another idea to handle larger interruptions is to create a temporary, special Scrum team. This team focuses on the special issue, solves it and then dissolves its members back to the normal teams. I described this idea in more detail at http://blog.dayleyagile.com/2009/03/20/minimizing-bad-effects-of-special-projects/. We have only used it once so far with a two person special team. It worked fairly well. I’d like to get more experience with it except the need for a special temporary team is also an indicator of other problems that I’m glad we don’t have!

  4. links for 2011-02-18 | Michael Ong | On9 Systems says:
    February 19, 2011 at 12:23 am

    [...] Minimising the impact of Sprint disruptions : Agile101 – Agile Project Management and Digital Publ… (tags: scrum agile disruption) [...]