When it comes to managing dependencies, teams playing Scrum need to master three key skills. They need to learn how to discover dependencies, how to capture dependencies, and how to remove and reduce dependencies. Teams that don’t build these skills will have difficulty getting things to done. Backlog items that they pull into a sprint may expand in scope significantly after the team starts working on them. Surprises may emerge over the course of a sprint that increase the effort needed to meet the acceptance criteria. Teams may be blocked because they have to wait for another team to finish work.
Discovering Dependencies
In Scrum, dependency discovery is a progressive and iterative process. It should happen at a high level when the Product Owner initially starts shaping the product backlog. It should happen again when the team refines those backlog items. It should also happen when the team plans their sprint. A good way to get teams started with discovering dependencies is to use some stock questions when they shape, refine, and conduct Sprint Planning. For example, they could ask:
- Does this backlog item depend on another backlog item?
- Does any backlog item depend on this backlog item?
When I work with teams on dependency skills, I encourage them to consider categorizing any dependencies they emerge. For example:
- Does it depend on a specific person on the team (a team member dependency)?
- Does it depend on another team doing part of the effort (a team dependency)?
- Does it depend on access to a particular technology or application (a technical dependency)?
- Does it depend on a vendor (an external dependency)?
- Does it depend on the order of stories (a sequence dependency)?
Knowing the dependency types that are in play for a backlog item will be very useful when the team tries to solve how to remove or reduce the dependencies.
Capturing Dependencies
Capturing dependencies is relatively simple. Most decent backlog management tools have the ability to capture dependencies and indicate the direction of the dependency. Some tools have an ability to capture dependency types. For those that don’t, I encourage teams to try to add a custom dependency type attribute to their backlog items, leverage an unused field in the ticket, or just add the dependency type info into the same area they enter their acceptance criteria. The goal is to capture the information and reference it when it’s time to solve the backlog item.
Removing and Reducing Dependencies
Removing and reducing dependencies is important to simplifying the complexity of a backlog item. Simply put, complex backlog items are harder to solve. They take more effort. Dependencies can be removed or reduced in various ways. For example:
- Combining backlog items
- Breaking backlog items down further
- Moving backlog items to another team
- Moving team members to your team
Like the discovery of dependencies, removing and reducing dependencies is a progressive and iterative process. Whenever a team discovers a dependency, they should categorize it before they work to remove or reduce it.
Final Thoughts
I haven’t said this explicitly yet, but I will now. The team that will be doing the work should be responsible for how they discover, capture, and remove or reduce dependencies. They need to own that skill. If the team doesn’t understand how to do this, their Scrum Master should show them. If the Scrum Master doesn’t understand how to do this, the Scrum Master should reach out to other teams in the organization to see what they do. The longer teams go without building dependency management skills, the bigger the impact will be on the team’s ability to deliver on their commitments.
Let me know if you have any comments or questions. You can reach out to me via email at FrankS@FreeStandingAgility.com
Thank you for reading.
Comments are closed.