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

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

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.