Tracking external dependency stories

Question

Say you have three projects. Two of these projects are end-user facing products (Project A and B). The third is an infrastructure project (Project I) where all the work will never be directly delivered to the end user. Instead the end-user facing projects will consume the infrastructure in order to be able to deliver there projects. All three projects are running under agile development and have their own, unique backlogs and reporting.

How does Project A reflect a story from Project I in its backlog?

I know this would be a dependency story, I'm just not sure the best way to reflec it.

• Shows as a zero point story in project A's backlog.
• Just listed as a dependency to whatever Project A end-user story relies on it
• Some other way?

Thanks...

Answer 1

A few approaches you might consider:

1) Don't start Project A or B until sufficient work (or the whole of) Project I is complete.

2) Since Project I has no external customer value instead of doing it as a separate project, have Projects A and B pick up those elements of it they need when they need them for the customer facing work.

3) Define the interface upfront. If, for example, part of Project I is to create a service that A and B will consume, define what that service needs upfront and ensure that any changes to the interface are communicated between teams so they can adjust as they go.

EDIT - expanding on 3.

This works where the customer facing teams don't need the whole of infrastructure work but will just consume parts of it.

Example:

• Infrastructure team is working on an account management system.
• Customer Service team is working on a system for customers to raise support tickets.
• Finance team is working on a system to allow customers to see their account balance.

Customer service team agrees that the infrastructure team will provide an API that allows them to pass a customers email address in and will return some data about the customer account, conforming to an agreed schema that contains information about the customer account allowing them to route the ticket to the right internal team.

The finance team agree that infrastructure will give them a pipe delimited flat file each night, delivered to a certain location via SFTP with a list of all account numbers and their associated balance.

All teams now have a clear understanding of the interfaces between systems and can work under those assumptions. The key with this approach is communicating if agreed dates won't be hit or if any team needs to change the interface for any reason.

Answer 2

Usually, dependencies won't just integrate and test themselves, so I would add an "integration [testing] with "Project I"" user story - or user story series* - to the backlog of "Project A" and handle as a typical user story: point estimation and priority.

Let's say the first estimation is 3 on this integration user story. You find some issues and they will generate user stories for "Project I" and/or "Project A" depending on their nature (for example "Project I" has to change its API because of incompatibility issues). The next time when you estimate the next user story you'll use the data from the previous one.

*user story series: there are reoccurring activities which the very same name and action, but in a different time like checking out the external dependencies. I like to create a new task for such an activities every time. It is easier for me to track and evaluate them.

Answer 3

There are a couple of items to verify. If the infrastructure team is delivering hardware/base components that need to be done for the other projects to complete or if they are delivering software interfaces. I am on a project where we executed without the hardware/base software installation complete and had to make informed decisions that affected prioritization on both sides to allow progress forward. If these are primarily software related, I would suggest that you need to make sure that there is good communication (scrum of scrum type) between the project I and A and B. Including the related projects in release/sprint planning as well as demos can provide a better understanding of the others who are dependent on you and what you can expect. In terms of the backlog, I would not track it as a unique story, but note it as a dependency on the story that consumes what Project I creates. That way you don't have something in the backlog that looks like it is free (from a point perspective) to deliver anytime. Make sure that as you execute, the interfaces and when they need to be ready play a role in prioritization across all the teams.

Answer 4

Having specialized as a UI developer and occasional Scrum master over the past 10 years, here’s what I’ve learned about external dependencies:

1. They’re always late.
2. They’re always buggy / different from what was expected.
3. By the time the whole system is working end to end and people starting using it, we discover a fatal flaw in the design that leads to a lot of rework.

Okay, not always, but I like to be pleasantly surprised.

With that knowledge in mind, I’ve had a lot of success designing stories that anticipate these challenges.

First of all, it’s a user story. We focus on creating value for the user. Sometimes we discover that a lot of the value can be realized even if the dependency is never done. For example, with a little extra processing, maybe we can get the data from an existing API. Even if it’s slower and missing part of the data, something may be better than nothing. Even if we’re going to throw that work away, it generally pays off in terms of time to market and learning.

When that option is exhausted, we start working on stories that can’t be completed without dependencies. The definition of done has a provision that a prototype may stand in for the real dependency. The team has to do a bit of extra work to build a prototype that may not even be used, but it pays off. It gives us a head start in finding our own bugs and we can get a close approximation of the full working system in front of the user faster. We sometimes learn things that will affect what we need from the dependency, so that we can redirect the other team, spare them some rework, and get the end-to-end project done sooner.

Instead of tracking third party dependencies on the backlog, we do everything we can to keep moving forward with or without the dependency. If we get to the point that we’re truly stuck and can’t do anything without the real dependency being done, we look for the next story on the backlog that doesn’t have a dependency. When the dependency is ready, we create integration stories just-in-time.