Customer Involvement

Prabhu TL
4 Min Read
Disclosure: This website may contain affiliate links, which means I may earn a commission if you click on the link and make a purchase. I only recommend products or services that I personally use and believe will add value to my readers. Your support is appreciated!

Customer Involvement has some positive and some negative effects on our core APD rework cycle. What could be considered a negative effect is the fact that continuous customer input results in a certain level of requirements churn. We model this (Figure 54) by calculating the Fraction of Release Work Completed. Based on this measure of work progress, we employ a lookup table in Effect of Customer Involvement on Requirements Churn. This variable represents the percentage of the requirements that will change based on customer input and how far along in the release we are. For the purposes of this model we are using a bell-curve reference mode, with a maximum of 10% churn. The rationale behind this is that the most churn occurs toward the middle of the release as tangible software is produced and allows the customer to feedback changes into the release.

The positive effects of Customer Involvement are captured in Effect of Customer Involvement on FCC and Effect of Customer Involvement on Rework Discovery Time.

Effect of Customer Involvement on FCC: A large part of software defects are caused by requirements uncertainty. As progress is made during each sprint, requirements uncertainty is eliminated with customer feedback and product demos. This in turn improves our FCC.

Effect of Customer Involvement on Rework Discovery Time: Likewise, customer availability to answer questions, detect conflicts and misunderstandings , and to identify usability issues during product demonstrations means that we are more likely to identify rework early in the process.

In Figure 55, we see the Requirements Churn Rate Based on Customer Involvement. This value fluctuates throughout each release between 0 and 30 tasks per week, in this example. In this simulation, we have four software releases, with three sprints in each release. Notice how, in each release, the requirements churn rate has decreasing several steps. These coincide with each sprint within a release – this behavior is intended to represent the notion that at the beginning of a release requirements are more fluid and subject to change, but as more sprints are completed and as there are less remaining features and work to do in the current release, there are fewer requirements subject to churn.

Below in Figure 56 we see also the Effect of Customer Involvement on FCC. As each sprint nears completion, the effect of having a customer available to validate work products results in an improvement in FCC, as uncertainty is reduced. Our model places a lower limit of 0.85 on this effect (Max Effect of Requirements Uncertainty) meaning that at worse, requirements uncertainty can reduce the FCC by 15%. In this graph we see the value for this effect climb up near to 1, then drop back down to 0.85 at regular intervals, coinciding with the sprints in the project. This behavior is intended to represent the fact that, as each sprint nears completion, the requirements for the features under development in this sprint are less and less unclear (especially with customer involvement in scrums and feature demos).

Share This Article
Prabhu TL is a SenseCentral contributor covering digital products, entrepreneurship, and scalable online business systems. He focuses on turning ideas into repeatable processes—validation, positioning, marketing, and execution. His writing is known for simple frameworks, clear checklists, and real-world examples. When he’s not writing, he’s usually building new digital assets and experimenting with growth channels.
Leave a review