One 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. :)
- Managing sprints alongside BAU (agile101)