In this post, I explore the Scrum value of focus, the notion of focus time and its implications for your Scrum team’s setup.
Focus as a Scrum value
Focus. It is one of the core values of Scrum, reminding us to be precise about our development goals and to stay on target at all times.
Focus tells Product Owners to build one product for a well defined audience, tells Scrum Masters to help their teams improve in one area at a time, and tells the Development Team to go for the Sprint goal and only the Sprint goal.
It is them - the team - I want to focus on in this post, although the thoughts apply to the other roles as well.
Recently, a client introduced me to the notion of focus time. By his definition, focus time is the part of a Sprint that the team actually spends working on product backlog items directly contributing to the Sprint goal.
Thus, focus time is comprised of all the work required to get one specific product backlog item from “ready” to “done”, including design, implementation, testing, documentation and posing the odd question to the Product Owner or relevant stakeholders.
It is not: Helping to prepare the next Sprint, demonstrating the product increment in the review, improving the process in the retrospective or organizing the team in the Daily Scrum.1 While all of these activities are important, they are by definition off-focus, as they do not directly improve the product2.
In an ideal setup, the team spends most of their time focused. The Scrum Guide allows for up to 10% of the development team’s time to be taken for product backlog refinement3, while planning, review and retrospective take up 10% of the team’s time yet again.
Another 5% are eaten up by Daily Scrums and general communication with people in- and outside of our product: Even the best of bosses and stakeholders need some attention from time to time.
This leaves our ideal development team with
100% Sprint time
- 10% refinement
- 10% planning, review, retrospective
- 5% Daily Scrum and communication
= 75% focus time
That’s 7½ workdays out of your two week sprint! Contrast that with the common complaint that Scrum is all talking and keeps people from getting things done.
Rare, however, is the team where all team member contribute all day, every day. The larger an organization, the larger its tendency to split people’s time and attention over several projects or products.
25 years ago, in 'Quality Software Management: Systems Thinking', Gerald Weinberg introduced us to the hidden cost of context switching, claiming that an even split across two projects left a knowledge worker with only 40% of his or her capacity to apply to each of them. (While Weinberg's original text is not available for free, his idea has spread beyond the cover of his book.)
So, let’s split some people and look at their focus time:
50% allotted time
- 10% context switching
- 5% refinement
- 10% planning, review and retrospective
- 5% Daily Scrum and communication
= 20% focus time
In case you’re wondering, I left the numbers for the four main Scrum rituals at their original value since all teams I have worked with so far insisted that their split members take part in all of them, since this is where the team makes all major decisions.
So, out of a promised 50% of somebody’s time and attention, only 20% contribute directly to the goals we set for the product – that’s hardly more than half of the 37.5% we might expect when looking at the original calculation.
Now, suddenly, Scrum is all talk and no action.
Said and done
So, the idea of focus – concentrating on what we ought to do – lead us to the notion of focus time, the time spent directly contributing to the Sprint goal. We have seen that ¾ of a team’s time could be spent focused, and that this number shrinks drastically when we split people’s time across products.
Now, I’d like to invite you to examine the time your team spends focused.
Do you get close to ideal numbers? Are you in the 20% range, even though everyone is on the project 100% of their time? Where does the time people don’t spend focused go and which of these activities are really necessary?
All in all: What could you do to improve the numbers?
Besides looking at things that distract the team, you might want to look at the product backlog items your team and Product Owner agree upon for the sprint. Is there a common theme, so that most or all of them contribute to a single goal?
If they have little in common, one could argue, there is not really one Sprint goal, and the team could never reach the lofty numbers I laid out above. However, there could be leverage in the way the Product Owner prioritizes the product backlog or the way you plan your sprints.
Let’s talk about your numbers and your findings in the comments!
Writing this post brought to my mind a number of questions, among them:
“What keeps teams from focussing and how to get back there quickly?”, “How to show the value of Scrum’s rituals to the ‘rather do than talk’ faction?”, and “Is focus time a good measure for the quality of a Scrum process? What other metrics are there?”Comment below if you have thoughts on any of these questions or are particularly interested in one of them.
1 Neither is it taking part in communities of practice, performance reviews, answering mails, general discussion or undirected learning, along with most other things team members like to do.↩
2 Actually, this is the main reason that some developers tend to resent them. Hackers want to do, not talk. As a Scrum Master, you could do worse than to think about this before your colleagues bring it up.↩
3 Note that this is not the established practice of a “refinement meeting”, but rather includes all activities dealing with the process of refining the product backlog.↩