Scooter-with-Baskets-182x182I once met a fellow professional who had 28% “Musts” on a project.  The client knew he should have 60% “Musts” and thought that he needed to “upgrade” some stories.  It took a while to make the client realize that he was actually in a brilliant position, one that most projects can merely dream about.

The reality for most projects is that they face well over the 60% guideline for “Musts” and, in my personal experience often face the challenge of 100% “Musts” and even pile more on top of that, just like the baskets on the scooter in the picture.

For example, a software house with multiple clients will have demands from most if not all of those clients for a release.  The pressure to commit to those requirements can be intense.

Indeed an internal I.T. department will often face a ‘wish-list’ of needs from their internal client, all of which are “absolutely” necessary.

In reality however, there is probably little to worry about if Agile techniques are used including MoSCoW prioritisation.  Once the requirements are broken down into stories the individual stories will become “Musts”, “Shoulds” and “Coulds”.  If that remains tough, when the acceptance criteria on the “Must” stories are set they can be prioritized to “Musts”, “Shoulds” and “Coulds”.

For example, a system requires the ability to search for and select a “Person”.  So, at a high level, it obvious that all of the following are also musts:

  • Ability to enter the search criteria
  • Matching “Persons” are listed
  • The user may select one.

If we put ourselves into the mind of a typical client, end-user, and consider the search criteria, he or she may very well have a “shopping list” of requirements such as:

  • Enter a Person’s name, exact match
  • Wild-card match
  • Sounds-like
  • Ignore case (because of poor quality data)
  • As I type closest matches appear
  • By Age
  • By Town
  • By X-km around a town
  • Save the search for a later date

From a solution and prioritization point of view, being able to enter a “Person” is a Must, a “Town” is a Should but “Within a radius of X-km (50 or 100km) of that town” is clearly a “Could”. An additional “Could” would be the ability to remember the search criteria for later use.

A development team may be very tempted to provide all to please the client yet the team needs to understand that it has to concentrate on the “Musts”, otherwise time, effort and money is spent on “gold-plating” or “over-engineering”. This takes discipline, which Agile projects need, probably more than traditional projects.

So, let’s assume that we are doing the “Must” to search for a “Person”. One may think that a new window is required.  Yet what are the acceptance criteria? It may be good enough to have just an extra field to enter a name and then a window listing the closest matches, where only one “Person” can be selected. But actually if there is already a form why not just enter the name in the pre-existing “Name” field and provide a new button, which lists all the matches in a popup window?

Clearly we are in the details of the solution but it is precisely these details that are necessary for the team to understand, agree on and be able to commit to.

An additional acceptance criteria may be being able to navigate the list with cursor keys and selecting with <Return> and this is a “Should”.

Thus, the absolute minimum, known as the “Minimal Usable Subset” would be:

  • A new button ‘Search’ is created on an existing form.
  • The user may enter a set of characters in the existing “Name” field.
  • On pressing the ‘Search’ button the system matches against the “Name” field and lists the matches in alphabetical order in a new window showing only Name, Age and Town (the sort order is fixed to Town then Age).
  • The user can select one by using the mouse and double clicking (key board selection not available).

The beauty of this example, is that the minimum is being delivered, but it is workable as a solution which the end-users can work with.

In terms of demonstrating iterative development, the next increment (in Atern terminology) or release can build on client feedback to add functionality that the end-users have come to recognize as those that they now most urgently need.  This most likely includes “wild-card matches” and “ignore case” but probably not keyboard selection.

In summary, when faced with a project or a release that contains all “Musts” the detail will determine the real split of “Musts”, “Shoulds” and “Coulds”.