Understanding and Apply Scrum [P8]: Scaling Scrum - Cross-team refinement in Nexus Flashcards
What questions need to be addressed for Nexus Cross-Team Refinement?
- Which teams pull what work?
- How can we best sequence the work, across Sprints and teams to balance early delivery of value against risk and complexity?
Who should answer the core questions of a Nexus Cross-Team Refinement event?
Development Teams
Who should attend Cross-Team Refinement?
- reps from each team
- based on the work being refined instead of the role that they play inside their team
- may be common to have different people attend these workshops based on the skills required
Who explains the PBIs to be refined?
PO
What size are the PBIs going into Cross-Team refinement? Why?
- large
- allows teams to id dependencies and decomposed based on skills and dependencies that emerge during Refinement
What will the early convo most likely be like at the start of the Refinement?
focusing on which teams have the necessary skills to do the work
When can work be taken back to the individual Scrum teams from the Cross-Team Refinement for normal PB refinement?
once PBIs are broken down more and better understanding achieved
How should dependencies be categorised?
- Build Sequence – An item cannot be completed until its parent is complete (can include technology, domain, software…).
- People / Skills – Only certain people / teams can complete an item.
- External – The parent item is being delivered outside the Nexus.
How can dependencies be visualized on the Cross-Team Refinement board?
- teams in rows - horizontal
- sprints in cols - vertical
- PBI in cells
- arrows showing dependencies - colour coded categories for dependencies
[SEE DIAGRAM]
Tips for creating a visualisation of dependencies of stories across several sprints for all teams
- minimum, consider identifying external dependencies with a color
- add additional color codes to denote common causes of dependencies in your organization e.g. Operations, Legal, DBA Team etc
What does an arrow represent in a dependency visualisation?
- direction of the arrows indicates parent to child relationships. (e.g. Item number 8 depends on Item number 4
- Commonly, teams will write a child ID on the parent card also
[SEE DIAGRAM]
Regarding dependency visualisation, what does a dependency arrow on an item highlight?
relationship of work
Regarding dependency visualisation, what do more arrows indicate?
high risk due to the number of dependent items impacted
Regarding dependency visualisation, what does visualisation help teams with?
identifying the ‘critical path’ of work throughout the upcoming Sprints and provides the basis for conversations about ways to remove or minimize the impact of these dependencies.
Regarding dependency visualisation, what does a left pointing horizontal arrow represent?
- dependency within a single team across time
- means that a single team is building an item in one Sprint that is needed by an item that will be delivered in a subsequent Sprint
- considered a low risk relationship
Regarding dependency visualisation, what does a upward diagonal arrow represent?
- dependency that is across teams and across time
- A team is building an item in one Sprint that is needed by an item that will be delivered in a subsequent Sprint by a different team
- Cross-team collaboration and communication will be vital to success.
- medium risk relationship
Regarding dependency visualisation, what does an upward vertical arrow represent?
- One team will build an item in a Sprint that is needed by an item that will be delivered in the same Sprint by a different team.
- This dependency gives little room for delay or unexpected
complexity. - This is a high risk relationship
Regarding dependency visualisation, do External Dependenceis have an ID?
- no
- they are delivered from a team outside the Nexus
Regarding dependency visualisation, what does a downward facing diagonal arrow mean?
- external across time
- team is relying on an item delivered by an external group in order to build a subsequent item
Regarding dependency visualisation, what does a downward facing vertical arrow mean?
- external and represents another in Sprint dependency
- team is relying on an item delivered by an external group in the same Sprint in order to build a subsequent item.
- an extremely high risk item.
What are some solutions to minimize and remove dependencies after they have been visualized?
- Moving work between teams so that there are less cross-team dependencies.
- Moving people between teams so that there are less cross-team dependencies. You may significantly reduce delivery risk if certain skills are rebalanced across teams for a Sprint two in order to minimize dependencies.
- Reshaping the work. By splitting items in different ways it may be possible to eliminate dependencies.
- Using different risk-based strategies. Some groups might try to entirely an ‘in-sprint’ cross-team dependency. Other groups may opt to front load all the risk as early as possible and take many cross-team in-Sprint dependencies in earlier Sprints in order to learn and respond.
Once the Cross-Team Refinement workshop is complete, what should we do to the Cross-Team Refinement board afterwards?
- Keep it up to date
- Ensure it visualizes the next ~3 sprints’ plans
After the Cross-Team Refinement workshop, what should the board be used as a focal point for?
risk-based conversations with appropriate stakeholders
Does Cross-Team Refinement replace individual Scrum Team Product Backlog refinement?
no
When should Scrum teams perform detailed Refinement inside their team?
Once the teams have agreed on the likely sequence of their work over the next few Sprints
What are some techniques to track dependencies over time?
- use the number and type of dependencies as an improvement measure → help track the impact of improvements to underlying architecture and working practices
- teams may also try to limit the number of dependencies they will accept, by limiting the number of arrows allowed
What events should information from the Cross-Team Refinement to taken into?
- Nexus Sprint Planning
- Nexus Daily Scrum
Why should info from the Cross-Team Refinement be taken into the Nexus Sprint Planning?
for the teams to plan for the current Sprint and its dependencies
Why should info from the Cross-Team Refinement be taken into the Nexus Daily Scrum?
used as a focal point for daily cross-team synchronization about risk and progress
