0

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?

user3251930
  • 177
  • 3
  • 2
    Question probably belongs to http://programmers.stackexchange.com... If you need to provide documentation for legal reasons price of changes could be so high that you will not be able to make incremental changes... – Alexei Levenkov Jan 30 '14 at 07:02
  • 4
    This question appears to be off-topic because it belongs on programmers.stackexchange.com – BЈовић Jan 30 '14 at 07:27

1 Answers1

8

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.

EvilTeach
  • 28,120
  • 21
  • 85
  • 141
Attila
  • 3,206
  • 2
  • 31
  • 44
  • 2
    I think this is good answer and concur - you don't appear to be *involving* your users in your development process. Maybe start at the wiki article on Agile Development (https://en.wikipedia.org/wiki/Agile_software_development) and work your way out into the greater world - there are hundreds (thousands) of web sites that can help. – robnick Jan 30 '14 at 07:10
  • 1
    Unfortunately we don't have users as part of the development effort. However maybe we should do usability tests at the middle of the Sprint as well? This will reduce the risk that we develop all this stuff that might not be eventually needed. – user3251930 Jan 30 '14 at 07:11
  • Yes, something like that could work. Even if you don't have access to your customer all the way during the development process you should be fighting to get more involvement by them. Make sure that they understand why it is so importent for them to guide your development efforts. It is not necessary to have UATs, but some kind of guidance during the sprint is fundamental. Daily involvement would be the best - example - every day from 10AM to 2PM you could get in contact with someone who can help you out, even on skype. Still better than nothing! – Attila Jan 30 '14 at 07:19
  • 1
    Okay, so a follow-up question. If things change often during the Sprint (because of user feedback) wouldn't that render team's commitment meaningless? – user3251930 Jan 30 '14 at 08:07
  • By the start of a sprint you should have a good undestanding of what the customer wants. You could be using user stories, or any tool that helps you to describe briefly the features that are going to be implemented in the system. These descriptions should be developed in collaboration with the customer. You don't have to fix everything in these, because you are going to have access to the customer during the sprint, so you can ask questions about further details. Just ask yourself: Which one you prefer, working all week on something that is not going to bring any value, or welcome change? – Attila Jan 30 '14 at 10:22