In Agile Scrum, the constant feedback loop allows developers to embrace change, within reasonable bounds. We demonstrate that software meets defined acceptance criteria to the Product Owner, and in some cases additional stakeholders, as part of getting user story work accepted. This gives the Product Owner and stakeholders an early opportunity to check not only that the software team implemented what was requested, but to reconsider if what was requested will ultimately meet the needs of the end user. Important features developed during a sprint are also demoed at the end of the sprint to a larger stakeholder audience, allowing for a broader range of feedback.
So what happens then if stakeholders don’t like what they see, now that they’ve had a chance to try it first-hand (assuming the system is performing as requested)? No problem… the Product Owner can create a new user story to capture the new desired behavior. The process encourages iterating on features, rather [than] resisting any and all change. Could constant requests to change the desired behavior become a source of frustration to the developers? Absolutely… but those changes do come with a cost, as planning new user stories for a future sprint may mean other work that was planned now needs to be pushed out to stay within the team’s velocity or capacity.
Ultimately I have found that the process leads to more satisfaction as a developer, as I’m able to deliver the “right” solution to the stakeholders and address their concerns in a timely manner. If, once the stakeholders have had a chance to see or try the updates from the current sprint and decide additional changes need to be made, I’m iterating on a sprints-worth of work (two weeks, in my case), not six months-worth of work.
-Mark R., Genova Software Developer