Differences

This shows you the differences between two versions of the page.

@@ Line 1: / Line 1: @@
+====== Why Don't Agile Tools Automatically Change Status When a Related Item Changes? ======
+While this seems counter-intuitive you will see that in general we generally don't want to do automatic status changes between items lower and higher in the hierarchy.
+====== Discussion ======
+Lets start with a simple example. Say we have a simple feature "owns" (many) stories type of hierarchy. We might look for the tool to automatically promote a feature to done just because we have completed all the stories, for example. However a feature is typically done when the person who asked for the capability says that the value has been delivered. This typically means that it meets the intent as expressed by the feature definition and the acceptance criteria but there might be additional considerations as we do work, and as we learn.
+In particular we want to avoid "we have to do all this scope to get this value delivered" type thinking. We might be able to get the value by doing only half the items we originally thought were required as we learn about what we do. On the other side, we might need extra work to deliver the value. In both situations we need to have an regular, explicit discussion about the value we are delivering before we change a feature's status - the fact that the PBI's are completed is an input into that discussion.
+The same kind of discussion can be had about epics and features, stories and tasks. And the same kind of discussion can be had about commitments at different levels. For example, there is typically a commitment process for features which is different to the commitment process for individual stories that are part of that.
+Summary of the thinking is that we are managing different levels of value delivery and should not use a task management approach to do this.
+{{tag>FAQ promote tool feature story}}
+~~LINKBACK~~
+~~DISCUSSION~~