Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
2  
Don't create new question. mark the original for moderator's attention, so he moves it. After all, you got really good answer –  BЈовић Jan 30 at 8:04
3  
What I'm wondering is: have you ever tried to find out why you apparently deliver so many increments the users don't like? Is there not enough communication with potential users? Is there no vision for the product from the PO? Are features misunderstood? –  Stefan Billiet Jan 30 at 8:11
1  
a: Why did you implement the feature? b: Some users will fight tooth and nail against any type of change but if you ask them 2 months after a change, they got used to it and will fight tooth and nail to keep the feature. –  Pieter B Jan 30 at 8:53

4 Answers 4

up vote 3 down vote accepted

Your sprints are too large or too complex. Your sprints are failing a key test, putting a lot of work in jeopardy. I believe that a risk (user's not liking an implementation) is not being managed fully or properly, causing extensive rework. Your team's project management style is at fault and you need to plan your sprints accordingly.

Paper or screen mockups, accompanied by lots of handwaving, are much less expensive than code to produce (I'm assuming: you might instead have a killer UI mocking framework). A walkthrough or role playing with appropriate test subjects takes dramatically less effort than building and making a system ready for deployment. Since you already know that user acceptance is high-risk, and that you likely won't get it right the first time, you can plan for multiple iterations within the current sprint in order to get the feature set right.

Since a sprint should not have deliverable elements that depend on elements from earlier in the sprint, you should not plan to deliver the UI/feature elements that you decide on during the current sprint. Instead, the results of the testing inform the planning and development of the following sprint.

In my experience, it is not unreasonable for a sprint to include, let's say, a) code and finishing for hard-and-fast features, b) tech spikes for sprints indefinitely in the future, and c) UI & feature tests for sprints in the near future. This allows you to manage the high risk stuff while continuing to deliver solid, acceptable code with all the proper documentation, etc, that accompanies a product release.

In my last project, we had a sprint constructed with a mix of a) a one-paragraph description of a feature or UI element for review by the user group, b) a screen-shot walkthrough and hand-waving session, c) a prototype ready for play-testing of a feature from a previous sprint, and d) a ready-for-final-acceptance testing feature that was first presented two sprints ago.

share|improve this answer
    
So you basically suggest two solutions: perform usability tests in mid-sprint (to see that we indeed make the right feature), or alternatively create prototypes instead of working code (which is much faster). Right? –  Eugene Jan 31 at 17:07
    
No. Perform early usability tests in the previous sprint for the features you are releasing in the current sprint. Nothing mid-sprint about it. Prototypes are a desirable mid-way point between paper/hand-waving and production code. Believe me, the increase in customer satisfaction, coupled with decreased development costs because of decreased (end-stage, hence expensive) rework will more than repay the increased amount of planning. –  BobDalgleish Feb 1 at 0:56
    
I understand, though that goes somewhat against the Scrum methodology of creating a working software each Sprint (rather than a prototype). This solution does make sense though. –  Eugene Feb 1 at 7:08
    
Then make sure to produce a potentially releasable product increment. The user testing or prototypes from the previous sprint can be made potentially releasable in this sprint. The code that you might release this sprint may contain only minor bug fixes, but the processes you carry out this sprint will include design, tech spikes, user tests, etc. –  BobDalgleish Feb 1 at 13:43

Scrum states that the aim of a Sprint is to produce a potentially releasable product increment. In the situation you describe, where users don't like what the team have produced, try to understand why. Inspect the reasoning and adapt accordingly.

The great news with Scrum is that you're finding these problems now, at the end of a Sprint and not at the end of an 18 month development project.

You may find that there's value in having the Product Owner engage more with the stakeholders to better understand their wishes and motivations. This, in turn, helps to order items on the Product Backlog appropriately and you may find that you're better able to delight your stakeholders at the next Sprint Review.

share|improve this answer

That is the Product Owner's responsibility -- to come up with a product that meets the needs of the users.

So you may wonder how your Product Owner wrote the user stories -- did he not check them with end users? Did he not create screen mockups for them to evaluate? Did he not gather their needs?

If users don't like what you did, the Product Owner must find out what must change and how, and then you can make those changes. If necessary (but unlikely I'd say), you can revert to the previous release and build from there.

share|improve this answer
    
Unless the product owner is testing user experience, none of what you say makes sense. –  BobDalgleish Feb 1 at 0:58
    
Bob, I respectfully disagree with that derogatory remark. Have a nice day. –  Roy Dictus Feb 1 at 16:04
    
I apologize for coming off ham-fisted in my comment. My point is that the Product Owner may be responsible for all of that, but they cannot really determine those things unless user testing is done. User testing involves design, coding and UI testing, including the hand-waving over sheets of paper mounted on a wall. That work has to be done somewhere by someone and has to be planned as part of the project. –  BobDalgleish Feb 2 at 13:09
    
Of course, and it is the Product Owner's responsibility. He has to make sure that the end users get what they need. If he does that properly, developers waste as little time as possible building features that nobody will use or want. –  Roy Dictus Feb 3 at 7:17
    
When the PO needs technical resources, such as UI designers, prototypers, etc, he draws them from the project team. Since these resources need to be managed as part of the project, they should be scheduled as part of a sprint, just like every other project resource. –  BobDalgleish Feb 5 at 13:43

It sounds like you need to engage more with your customer.

Maybe you tried to already and they will not engage because they are busy with what they see as their "real job". If so, at a higher management level, IT need to get buy in from customers to be more involved with the project.

Early prototyping phases might help.

Somehow making them aware of the cost might help, although binning say 2 weeks or work should be indication enough. Moving shipping dates or cutting features from future releases might focus their minds.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.