Skip to main content

Context Switching Its That Important?

Last post 07:30 pm March 11, 2020 by Stijn Decneut
3 replies
05:50 am March 11, 2020

There are quite a fair amount of article talk about Scrum team shouldn't do context switching whereby the team should have full focus on whats on the project / sprint goal once the sprint has been lock down

My questions is , imagine in a work environment whereby need to assist company client and there always an ad-hoc task coming in , what will be the best approach here? In an ideal world no matter how well plan there always a impromptu situation.


01:52 pm March 11, 2020

What does the Product Owner think about these ad-hoc tasks? Does he or she believe they help to maximize product value?


04:13 pm March 11, 2020

If the tasks are to assist the company client then I would suggest a support team that works based on a ticket queue and let the Scrum Team focus their attention on a Product Backlog that creates additional value for the company client.  They do not have to be the same set of tickets. 

Reality is that organizations will often have groups that do work that are not organized around Scrum.  In this case the support team would be a source of information for the Product Owner's efforts in determining changes needed to the product.  


04:48 pm March 11, 2020

First of all, is this a product development team or a service delivery team? In the latter case, e.g. a Service Desk, I'm not convinced the Sprint mechanism of Scrum is most suited for them.

If it is a product development team, the Scrum Guide is quite clear on this: "Dring the Sprint: No changes are made that would endanger the Sprint Goal;" It doesn't state that teams are not allowed to do anything outside of their Sprint Goal, it just stresses the importance of prioritising the Sprint Goal over other activities.

A bit of ad-hoc work during Sprints is actually a good thing. It shows that the team has the confidence to start sprinting without having sorted out all petty details during refinement or Sprint Planning. Even the purest of Scrum teams regularly take up unplanned work during their Sprints, if only to support the production environment of their previous Sprints' Product Increments. As long as the Sprint Goal remains valid, the Sprint goes on. There are simple, elegant techniques for that, usually combining a Kanban Method-light approach with the Sprint Backlog. 

Having said that, if your team is spending large amounts of time during their Sprints on ad-hoc work, it could be a sign that: 

- the Product Backlog lacks stability or clarity: Can these ad-hoc tasks be avoided before the sprint starts with more refinement work?

- the Product Owner lacks the mandate to fix the team's focus for the duration of the Sprint and to postpone ad-hoc requests to later Sprints: are the ad-hoc tasks prioritised by the Product Owner based on a product vision?

- functional/technical debt is causing unexpected 'urgent' problems to occur regularly. Lowering the team's velocity may be a good idea, so they can clean up historic debt.

Final note: I wouldn't link this situation with multitasking as such. As long as ongoing tasks do not need to be interrupted on the spot and the team is able to re-plan their work with the new tasks (e.g. during their Daily Scrum) in a way that works for them, no problem.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.