Product Backlog or Wishlist?

The Requirements Discovery Canvas is a visual tool that helps teams discover and organise software requirements. Inspired by the Business Model Canvas, it provides a framework for collaboration, that can be used by both agile and traditional software development teams. In this post, I am going to focus on the “Features” column of the canvas which prompts a team to answer the question, “How could the stakeholders use software as a tool?”.  The other columns of the canvas provide the context for answering this question with the canvas as a whole providing a visual framework for organising what the team discovers.

For agile teams the “Features” column represents a product backlog, which drives release planning and incremental delivery of the solution.  For traditional teams, the “Features” column represents the initial scope  of the solution that will be later elaborated into detailed requirements.

For both types of team, it is important that the list of features does not degenerate into an unruly wishlist of disparate features.

Wishlists We are all familiar with wishlists. They are used to record the desires of individuals or groups. My dictionary tells me, that as well as “expressing a need”, desire includes “the feeling that accompanies an unsatisfied state” and “an inclination to want things”. If the criteria for adding items to a wishlist include “inclinations” and “feelings” it is fairly obvious that a wishlist can be quite subjective.

Wishlists are created and managed in a variety of ways. Proactive vendors of software products often establish online wishlists using specialist software such as User Echo. In the absence of a vendor managed wishlist, users often resort to online forums and social networking sites to express their desires. Vendors ignore these informal wishlists at their peril. There are many examples of software vendors being foprced to  add or reinstate features as a result of online user campaigns.

Support desks and call centres could possibly become be a rich source of customer wishes. But it seems that few organisations manage to collect customer feedback from this source.

The traditional way of establishing a wishlist is through information gathering activities designed to elicit wishlist items. For software products, the two most favoured approaches are user workshops and interviews. The Requirements Discovery Canvas can provide a framework that both prompts an interviewer and provides a place for them to record the questions they will ask and the responses they receive. While populating the canvas with coloured sticky notes is an ideal activity for requirements workshops.

One of the problems with workshops and interviews is that, when asked directly, users often have difficulty expressing their desires! Barry Bohem calls this IKIWISI (I’ll Know It When I See It). Interestingly, the same users will later have no difficulty generating an extensive wishlist once they do see the product.

IKIWIS is one of the motives behind the final column of the canvas which prompts teams to focus on and prototype user interfaces.  

Popularity It is obvious that frequently requested features should grab the attention of product developers. Tools for managing user wishlists such as User Echo allow users to vote for wishlist items (for a good example of this in use, see the Cinta Notes product roadmap).

The App Store and Android Market both allow users to review and rate products but don’t permit users to add wishlist items. As a result, it is quite common to see users requesting features in their review or even qualify their rating with something like “…would give it five stars if it had…”.

While it is true that there is strength in numbers, we should not forget the tyranny of the majority. It can be dangerous to simply ignore what appear to be unpopular features. Further investigation might reveal a small group of users with special needs such as the need for enhanced accessibility. Ignoring unpopular features also increases the risk of missing a highly creative approach that few have thought of.

When it comes to filtering unpopular features, it is sometimes more effective to ask users to vote items off the wishlist (in the style of reality TV shows). Casting a vote to remove an item from the wishlist encourages users to think about the consequences of removing a feature rather than focussing on their wishes and desires.

Ambiguity Features are described using short natural language statements that can be ambiguous (even before the jargon of software systems is introduced). For example, it is quite common for users to request that products are “user-friendly”, “easy to use”, “easy to change” or “have a fast response time”.

In the absence of any quantifiable measures, request such as these are pretty meaningless as they simply describe subjective desires. Even if they were taken seriously, it would also be impossible to confirm that the user’s wish had indeed been fulfilled.

Acceptance Criteria Insisting on clear acceptance criteria for each feature on the wish list is one very effective way of reducing ambiguity.

Another benefit of acceptance criteria is that they help to counter balance the rather abstract nature of features by providing concrete examples. Imagine a wish list item that requested the following function “calculate accommodation charge”. In the absence of acceptance criteria, this feature is very abstract. Asking the user to identify acceptance will help to clarifying their intent.

The example above clarifies that for the feature “calculate accommodation charge”, the number of nights are calculated by subtracting the check in date from the check out date.  The exception to this is a guest who checks in and out on the same day but will still be charged for a single night’s accommodation. The example also shows that guests that stay 10 days or more receive a 10% discount.

IKIWISI IKIWIS can be another source of ambiguity. Although to be fair, it should only be considered a problem in certain situations. Often the IKIWISI approach can be very effective. For example, I may know that I need a new shirt but have no idea what sort of shirt to buy. I set out shopping confident that “I will know the right shirt when I see it”.

Shopping as a technique for clarifying what we need works well for clothes but is more difficult to apply to software. The App Store and Android Play usually offer free and paid versions of an app which allow users to try out several competing products before deciding on the exact features they need.

However, when software products are developed for a specific target group of users, it is not really practical to create a market place of alternative solutions and use a “shopping-driven” approach to clarify the user’s wishlist.  

In this situation, the prototypes can be a cost-effective way to provide users with an IKIWISI experience.