What if Users Don't Like the Latest Potentially Shippable Product Increment?
11 January 2016
One of the most common problems organizations have in using Agile for incremental software development is users' disapproval of the latest increment. Even though it seems like a big problem, when compared to the Waterfall approach (wherein we're unable predict the problems the user might raise untill the product is deployed), it is better to know that a small increment of the product failed rather than that the complete project failed. So, we'll discuss a few strategies for contingency measures as well as ways to avoid rejected increments.
A simple way to handle the failure of an increment is to roll back the whole increment. This is not the best solution for the situation; it is only implemented if there is no other alternative. Use this solution only when the cost of the increment is relatively lower in comparison to the overall project cost, not only in terms of money but also in terms of the human resources used and the time spent.
Another way to handle the situation is to make amendments in the increment according to the client's user story, and to consider the feedback. This solution depends on the flexibility of the features added specifically in the increment and also on the pre-incorporated features in the whole release. You must also consider the cost of all changes while presenting this approach to management.
We firmly believe that we can follow any of the methods below as strategic approaches to help avoid the risk of increment rejection.
Usability tests can help. One strategy is to perform a usability test at the end of the increment and then produce only the release to the user. The results of this test will decide the future of the increment. If the test produces a negative result, we can either completely ignore the increment or handle the issues in the next increment. It is better if the usability test is carried out before the bugs are fixed, testing and documentation are done, and changes to the user interface are made. This prevents extra work generated when the usability test fails. Perform usability testing soon after the core functionality of that particular increment has been addressed in development.
That approach works fine for small increments, and to some extent for medium-scale ones. However, it is not a good strategy for a major increment in the project.
Use a modeling method before you proceed with real code development. Adding a few features of the prototype, making the prototypes, and conducting usability tests on them can be helpful. Sometimes even a rough sketch of the plan explained to the client in an efficient manner before proceeding with actual code development can also yield favorable results.
For extremely large increments, it is also necessary to conduct usability tests midway through the increment development, in case we might be heading in the wrong direction. Thus, continuous monitoring of the increment process, rather than waiting for the completion of the increment and then checking for acceptance from the user or client, can be a good approach.
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
Current rating: 4.5 (4 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.