Delivery practice questions

An average satisfaction score can hide groups moving in opposite directions. Evaluating satisfaction includes segmenting by customer type and acting on a group whose experience is getting worse.

The flat average masks a 1.2-point fall for a third of users. The product owner should find out what in recent increments hurt night-shift nurses. Keeping priorities trusts the misleading average, serving managers helps the group already improving, and chasing more responses delays action on a consistent trend.

1. Look past the average to the segments.
2. Spot the group whose satisfaction is falling and how large it is.
3. Link the fall to what changed in recent increments.
4. Investigate that group before re-ordering the backlog.

Exam tip: A steady average can hide a group that is getting unhappier; segment before you conclude.

Agile teams evaluate customer satisfaction regularly, after each increment reaches customers, so the trend can guide the next increment.

A trend measured release by release shows the effect of each increment and leaves time to adjust. An end-of-project survey comes too late to act on, a product owner’s rating is not the customer’s voice, and accepted stories measure output rather than satisfaction.

1. Ask when the information is needed: while there is time to change course.
2. Prefer a short measure repeated after each release.
3. Make sure the measure comes from customers, not proxies.

Exam tip: Measure customer satisfaction little and often, so each increment can be judged while you can still act.

A satisfaction measure must fit both the goal and the audience. For a mandatory tool, usage measures reflect obligation rather than satisfaction, and a goal about ease calls for an effort measure.

Two facts decide this: the users are captive, so usage-based measures stay flat whatever the experience, and the goal is about tedium, which is what customer effort score measures. Asking right after the task also gives a reading per increment. NPS fits loyalty in markets with choice and is collected too rarely here; claim volume is driven by business activity.

1. Note that users cannot switch, so usage does not reflect satisfaction.
2. Note that the goal is about effort, not loyalty.
3. Pick the measure that asks about effort at the moment of the task.
4. Check that it can be read after every increment.

Exam tip: For captive users, usage is not satisfaction; measure what the goal names, at the moment of use.

Delivering work in small increments shortens the time between building something and learning whether it is right, which lowers the cost of being wrong.

Each small increment invites real feedback early, so mistaken assumptions are corrected before more work depends on them. Testing effort is not reduced, scope is deliberately kept open, and stakeholder involvement usually rises rather than falls.

1. Ask what small increments change about feedback timing.
2. Link earlier feedback to the cost of correcting mistakes.
3. Reject benefits that agile does not claim, such as less testing or fixed scope.

Exam tip: Small increments make mistakes cheap: you learn you are wrong before you have built much on top of it.

Large batches delay feedback until the end. Splitting work into small, usable increments lets the people who can judge quality check each piece early.

The constraint is that only hands-on use reveals bad data. Migrating in small batches gives users that hands-on check within weeks, not months. A late trial migration and automated reconciliation are both useful, but the first gives feedback too late and the second cannot judge usability. Signed specifications are reviewed on paper, which the users have said is not reliable.

1. Identify who can judge the result and how: users, by working with the data.
2. Ask when each option first gives them something to work with.
3. Check whether automated or paper checks meet the stated constraint.
4. Choose the option with the earliest real feedback per batch.

Exam tip: When only real use can judge quality, split the work so real use starts with the first small batch.

Releasing an increment to a limited group of real users (a pilot, beta or canary release) gets genuine feedback early while limiting the impact if something is wrong.

Both requirements are met only by a limited release: feedback comes from real customers, and exposure is small. A full release with rollback exposes everyone, while a sales demo and staff testing produce opinions from people who are not the customers.

1. List the two requirements: real-customer feedback and limited risk.
2. Check each option against both.
3. Pick the one that gives real use to a small group.

Exam tip: To learn from real users without betting everything, release to a few first and compare.