Experience Sharing: What is the Scrum value of “Focus”
As a scrum master, I want to help the team resolve the impediment so that they can focus on the sprint goal. When you hear that a team member told us he cannot focus on his development task due to multiple reasons, to resolve the interruption impediment, I think you can find some ideas in this blog post.
What is the Scrum value of “Focus”
“Focus” defined in the Scrum Guide: The Scrum Team commits to achieving its goals and to supporting each other. Their primary focus is on the work of the Sprint to make the best possible progress toward these goals.
“Focus” defined in the Scrum@Scale Guide: Focus and Commitment refer to the way we handle our work obligations, putting customer value delivery as the highest priority.
Interrupt due to requirement change
One team member yelled: “The product owner(PO) changed the requirement in the middle of the sprint so that I cannot focus on my commitment!”
I agree that product owner changes the requirement in the middle of the Sprint is acceptable if it brings more values to the customer. We can negotiate with our product owner if we don’t have enough capacity, drop-out the low-priority tasks is a good practice.
As a Scrum Master, I think we definitely need to let our product owner know that frequently change during sprint bring risks to decrease team’s velocity and the project schedule. Remember the agile principle – “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
Interrupt due to unplanned activities
One team member yelled: “I have higher priority bugs been assigned, I cannot focus on my sprint goal!”
I think we should fix the bugs when they arise, and try to make unplanned activities convert to planned activities. We should know that relegating bugs that will require a large amount of work to the product backlog.
As a scrum master, we should always help the team to plan time for the unplanned activities, high-priority bug fixes is one kind of the unplanned activity. Encourage the dev team to pick up the incidents, take the chance to re-dispatch issues during your daily stand-up meeting when needed. Remember the agile principle – “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
Interrupt due to tasks from other stakeholders
One team member yelled: “My manager let me develop a PoC in the middle of the sprint, I am sorry that I cannot focus on my tasks.”
Typically, we do the initial analysis when we receive the request from managers, say NO to the managers directly is not the best choose if the requirement is urgent and will impact the customer success.
As a Scrum Master, firstly, I think we should let this additional task transparency to the whole scrum team, analysis the priority and the impact. Then negotiate with the manager when needed – whether we can pick up his task in the next sprint, then we can do a better planning and not impact current sprint commitment. Encourage the developer to do it, show trust to them. Remember the agile principle – “Build the project around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
Never forget to discuss with your product owner, since he knows which backlog item bring value to the customer. That’s why here is another principle – “Business people and developers must work together daily throughout the project.”
In my understanding, “Focus” is based on the sprint goal, the nature of sprint goal is the valuable software which help the customer improve their competitive in the market. So, when we receive interruption impediment from the dev team, let’s firstly think about the impact to the customer success.
This is Ling, interested in agile software engineering, I am the certified scrum master, I’d like to discuss this topic with you, feel free to note down your ideas and your questions~ 😉