Table
We may consider product development as a system being controlled by information feedback. The Product Backlog is then the result of the initial Product vision and its adjustment by feedback collected all along the project life.
How important is the feedback
Product development starts with expressing a vision and its translation into functional needs: the Product Backlog.
At the end of each development period, the generated product increment is demonstrated to stakeholders, i.e. anybody having expectations regarding this development. We expect they react by expressing information feedbacks.
This information feedback is used to control the Product Backlog as expressed in the following diagram.
Product Backlog feedback loop
So, after many iterations, the Product Backlog really has changed. Its functional content has been reviewed or even renewed. And the Product Backlog also contains all discovered defects (bugs). whether they contribute to readjust functional content or they express defects, information often come from feedback given during product increment demonstration.
How long shall last this feedback loop?
The more the retroaction loop is short, the more the system may adapt. When this loop is very long or does not exist, we face the tunnel effect.
So we need to reduce this loop delay as much as possible.
Besides, developers need time to build the solution they will expose. An inclination to perfection leads even them to continue until they gave the final blow to their product.
Thereby, the agile iteration duration shall be the best compromise between the need of quick feedback and the delay necessary to the development team to produce a positive result.
In flow mode, the vocabulary sticks even better to this notion. We are looking to reduce the cycle time the same way we reduce the iteration duration. The demonstration of any increment provokes a feedback that will feed requirements expression.
How to practice it easily
The helium stick game provides an excellent mean to feel this need of information feedback. When one understands that feedback is the missing part, he quickly find this little game solution.
Summary in one Moto
Contrarily, as long as there are no feedbacks, there are no reasons to change. This leads to define this moto :
No Feedback, no changes!
Source
This article is greatly inspired from Gunter Verheyden’s diagrams in his article on sprint cadence at scale.