Potentially Shippable Product Increment - what if users don't like the latest increment? [closed]

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

This question does not appear to be about programming within the scope defined in the help center.

Closed 8 years ago.

Improve this question

In our company we do usability test at the end of each Sprint. Many times we discover that the users don't like the implemented feature, so we either completely change it or scrap it in the next Sprint.

However if we start doing potentially shippable product, thus fixing all bugs, running a lot of tests, preparing documentation for FDA and for users, fixing little UI issues - all this work will go to waste if users will not like the feature. Isn't it better NOT to do all this extra potentially shippable stuff until we are sure users actually like the feature?

Answer 1

If you face that users don't like your last increment, that is because you missed a critical point. You should have higher customer involvement all during the sprint, thus making sure that you are really making what the customer wants to see.

If you have a customer representative helping you all the sprint, it is not likely that you are going to implement something that they don't like. If you already do it like this, maybe you should improve your communication. You should have your customer guiding you all the way, helping to find the way they going to like it.

So, the answer is yes. You should make sure that the users really wants this, and this way, but instead of waiting for the end of the sprint you should go and get feedback much earlier, during the sprint and user story definition; minimizing waste and maximizing word not done.

Let me recommend you a great book on Agile:

The Agile Samurai - How Agile Masters Deliver Great Software

If you do not have access to a customer representative during the development process (which is the case in this situation, based on the comments), you should make sure that your customer has a good understanding of why it is needed. Make sure that they understand if they won't guide you, you are not going to be able to deliver superior, word-class quality software.

As part of an agile team, and as a whole team you should be fighting for higher customer involvement.

And one more thing, that people tend to forget. Go your own way. Agile is just about sharing some good practices working for people, and willing to share them. Some people did it this way, so they sharing the knowledge. If it is working a bit different for you, that is just OK.

A way to go could be for you, as you wrote: show your customers the new features, the more times, the more involvement, the better. Show them the user stories, show them the mock ups, show them the half working solutions, communicate with them; get the most out of the situation, and the most information about their expectations. Make sure that you get the necessary feedback in time, this way you can make sure that you won't end up again, standing there during the sprint review and having something that they don't like.