Lack of concern with risk to sprint goal
During standup a team member let the team know the sprint goal may slip because he's running behind on his tasks - as he is a designer nobody else can step to help - he's not too concerned about the risk. As a scrum master, how would you recommend approaching this lack of concern - retrospective / other?
Raise the issue in sprint retrospective is the baseline.
During the sprint:
Let PO know the issue as he is accountable for the value and risks of the product.
Co-work with DT to identify the risk and coach them that they are a cross-functional, self-organized.
The SM must know the real mind of "nobody else can step to help" is a attitude issue or skill issue.
For a attitude issue, coach them.
For a skill issue, maybe the other teammates could not step to do the designing task directly, they could help some tasks relatated to design, such as layout, UI component, etc. This is a learning process of DT.
Do some exploration into the root cause of why he’s running behind his tasks, there may be bigger underlying problems there.
1) Organise a one-on-one meeting to talk through what he understands the “Sprint commit” to be, and self-organisation of teams. This is a good coaching opportunity on core Agile and scrum principles.
2) Try to dig deeper into his design estimation process. Design can sometimes be a bottleneck. What is the demand by the team on him?
3) Would a “definition of ready” for UX and design help? Think through any customer data required, design principles/concepts, feature maps, style guide, brand guide, component guides etc. Work with the PO to help shape these as it needs wider business engagement. Having these in place can speed up design processes and other team members could potentially pick up design tasks helping to tackle the cross-functional aspects of teams.
4) UX and design processes require creativity and can be difficult to timebox. Try to get the designers to look ahead working as part of the user story refinement process and release planning, working one sometimes two sprints ahead of the development team allowing for creativity, reducing risk and increasing predictability in project delivery.
Jitesh
Thank you guys. I have lots of food for thought with your answers. Definitely re-looking at our Definition of Ready and re-visiting Sprint Commit and estimation could help here.
We already design ahead of the developers, but I agree this is a good way of giving the designers space to be creative.