Agile/Scrum- 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.