To a large extent, this is a good situation because the team is self-organized and showing good signs of maturity. From a Bruce Tuckerman's team point of view, they are in a "performing" stage. But, should the team member waste their capacity? Let us look at a few scenarios.
First, should the scrum master assign any task to fill the capacity? Well, the scrum team breaks the user stories into tasks. So, assigning new tasks to that member is not promoting self-organization. On the other hand, the scrum master should coach the individual to look for opportunities where they can add value. If the goal is delivering incremental value, then, what can they do? Updating documentation, refactoring code, taking training, and improving CICD processes are all examples where they can add value.
Second, should the team member review the backlog and pick up user stories to add to the current sprint? Well, this is a two-part question that has different answers depending upon the business practice. Anyone following the Scrum in theory would advise that additional user stories can not be pulled into the current sprint that would endanger sprint commitment. If you parse this point, no work can be added that would compromise sprint commitment. That is true! But sprint commitment is by the team and not by an individual. If the individual has already asked the other team members to support on their sprint commitments and have no team member needs the assistance, then, sitting idle and wasting capacity is not going to add value! This is where the Scrum is also forward looking suggesting backlog refinement as an additional ongoing/continuous activity. So, the team member can rightfully review the backlog (which by the way should be prioritized by the product owner for at least two upcoming sprints) and more clarity from a customer, business, technical, and process stand point.
A good product backlog should also have some experimental stories - not himportant now but may be in the future. Recall Scrum approaches also recommend the MoSCoW (Must, Should, Could, Won't) for prioritization. So, reviewing and perhaps even picking those research oriented spikes is definitely an option. Since not finishing them does not compromise the team member's commitment, unless of course their work is in the direct critical path of the existing sprint commitment of others, then, working on such experiments only add value. For instance, an AI based experiment to do things better or automating some work to improve CICD processes, etc.
Finally, can the team member pick one of the prioritized stories and possibly begin working on them. Designing or developing on that user story is sometimes looked down upon because that work can not then make it to the current sprint. If work done on that user story not committed to the current sprint is proactively being worked on, only because the current team member does have excess capacity that the scrum team cannot leverage, then, such a proactive work can make it to the next sprint (because it is prioritized high already in the backlog) with a lead on the schedule for the next sprint. That is facilitating the delivery of working software faster!
In summary, having excess capacity is an opportunity. Scrum is mainly about working agreements among the team members. It is an opportunity to look at these ideas and see how cross-training, documenting, role-playing, and experimentation can all be factored into backlog and agreements made when such opportunities arise. Wasting valuable resource time neither contributes to productivity or throughput and only contributes to waste (non-utilized resource is one of the lean waste). So, build quality more consciously in scrum.
Thoughts?
