Back in 2019 I wrote this – “Managing and tracking dependencies is another key aspect that an Intelligent Backlog should be able to help with. If there are several stories that are linked via a dependency then this should be made clearly visible and taken into account whenever the priorities of the stories is being assessed. The value of a particular feature probably depends on getting all dependent parts completed so from a value-stream perspective the ability to track and manage dependencies so that all required stories can be delivered as closely as possible to each other also clearly makes sense”. For full post see here.
If we are tracking features then we can assume that each feature contains stories and defects that may be dependent on other stories and defects within the same feature. Where it gets tricky is if there are a large number of dependent stories and defects, now we are in danger of having a very large feature that is no longer expected to act like a flow-item. The progress of these large features will be more glacial, they may take the majority of the release timeframe to be completed. Where we decide to arbitrarily split features in order to allow them to flow we need also to be aware that we may be putting dependent stories in separate features. One solution to this would be to have a dependency attribute that can be set to indicate dependencies between features. In terms of value this also gets interesting as the value delivered by a single feature may not be realized until all of the dependent features have also been delivered.
Managing and tracking dependencies is always going to be an important part of understanding how our payload can be delivered and how the associated value can be affected. Keeping all dependent stories and defects within a feature or related features is a good way to make this clearer. Where work is split across several teams we may not be able to use an iteration as an appropriate measure of time (unless the teams sprints are aligned). Maybe a typical unit of time to measure feature progress is a month, for several features that are being worked on by several teams we need a way to summarize what we’re expecting to happen – for example
Feature A (dependencies: Feature B and Feature C, reason: to realize perceived value)
Progress: 7 out of 8 stories completed (Blue team have story 8 in current iteration)
Feature B (dependencies: Feature A and Feature C, reason: to realize perceived value)
Progress: 2 out of 5 stories completed and 2 open defects (Green team have two stories planned for next iteration and Yellow team are currently planning to complete the remaining story in three iterations time. Green team can allocate two defects in sprint after next.
Feature C (dependencies: Feature A and Feature B, reason: to realize perceived value)
Progress: 3 out of 5 stories completed and 2 open defects. Green team have one stories in current iteration and Blue team have a story planned for next iteration. Either Blue or Green teams can allocate defects into next sprint.
Now we’re in classic “Critical Path” territory – currently Feature A looks like it will be completed first at the end of the current iteration. Feature C looks like it can be completed in the next iteration and then Feature B in three iterations. All of this can change of course(!) there could be issues, defects, changes in priority that impact this. We could decide to increase the priority of the story that the Yellow team are planning to work on, if we can do this in the next iteration and everything else stays are planned then all three features would be completed at the end of the next iteration. Assuming that the Yellow team are on the Critical Path and we can’t change their schedule (complete in three iterations time) then we can debate the importance of maintaining the schedule of the other work – for example, let’s say that the Feature A story that the Blue team are working on becomes blocked and gets carried over into the next iteration, what impact does that have? It doesn’t have an impact on completion of all three features but it does delay completion of Feature A by an iteration. This in turn may delay when the Blue team can work on the defects associated with Feature C so we can start to see that although some delays might not directly impact the Critical Path if these delays and changes build up then it becomes more and more likely that the Critical Path may become impacted.
In this example I deliberately put the dependency reason as “to realize perceived value”. Of course, there could be other reasons why a feature is dependent on another feature but I wanted to return to a point that I made earlier in this post – where we decide to arbitrarily split features in order to allow them to flow in terms of value this may not be realized until all of the dependent features have also been delivered.
Dave Browett-Agile Proj Mgt 