When a completely new system is going to be build or an old system is going to be rebuild completely there is a phase in which the scope of the system is defined and from this product backlog items emerge. In most cases this happens in workshops in which business analysts, end users, testers and other stakeholders participate. Usually developers are not yet involved in this phase. The product backlog items together describe the system to be build and can be translated one on one to (smart) use cases, data flows or any other artifact representing a piece of functionality. One or two sprints before a product backlog item is taken into sprint some more detail is added to the product backlog item, usually by writing functional documentation on a high level, leaving out details that can be added later. When the product backlog item is taken into sprint, the whole development team looks at it together with the stakeholders, filling in details and finding the best solution together. During sprint, the item is build and tested and the documentation is written in parallel. Interdependencies between the backlog items can be seen using models. See below for an example of a use case model, in which it is visible that the use cases “Select process” and “View total day production” have dependencies with both the use cases “Approve registered production” and “Register day production per employee”.
When a system in use is developed further, product backlog items are continuously being added to the product backlog by the product owner. Input for this usually comes from sprint demos or from workshops with stakeholders. In this case the product backlog items can be new functionality to be added to the system, changes to existing functionality, performance improvements and bug fixes. The items usually require changes to one or more existing pieces of functionality. In that case, before the item is taken into sprint the impact on existing functionality should be known and the documentation adjusted during sprint. If for every backlog item it is known what parts of the system it impacts it is easier to find interdependencies.
To conclude: I have found that in cases were visual models were used interdependencies were more easily found. Also, having some level of system documentation that represents the current state of the system is necessary to be able to make changes to an existing system. A good basis for this documentation are (smart) use case models. But documentation and models are not enough, still a person or team that knows and understands the complete system is needed to develop high quality software (individuals and interactions over processes and tools). Concerning the team I worked in: I think there were quite some things I could do to make my life and that of my team members easier by introducing some visual models. Unfortunately, I could not stay around to make these improvements due to pregnancy, but I did use my findings in my later projects and will continue to do so.
