By Brian Lucas

This one is for all the children who did not have an Easter to remember!

“Speak clearly, if you speak at all…” – Oliver Wendell Holmes, Sr.

Jane, an IT friend of mine, who was in town, joined me for the festivities during the Easter meal at relatives and friends yesterday. We dined throughout the long day on a marvelously succulent wild boar with sweet potatoes, corn on the cob, homemade raisin walnut bread, peas in white gravy and candied carrots. It was accompanied by some very nice homemade apple cider and a seemingly endless assortment of pies, cakes and an unfortunate mountain of various sweets. For entertainment, we watched invading hordes of children track an impressive amount of mud throughout the house from what was by all accounts an epicly successful egg hunt. At one point, she turned to me and said the user stories her company was producing were sometimes as muddy as the children’s footprints.

She then took the opportunity to bemoan their failure in adopting what I call “agile speak” and asked me if I had any suggestions that would help. I told her that the latest trend I have seen in very successful agile development operations was to “externalize” their user stories to segments of their existing and/or potential customer base. It is essentially an aspect of crowdsourcing your requirements. This has two benefits. First, it ensures you are using language that your customers can understand. Second, it gives you a verification of the validity of what you are trying to develop before you do so.

What impressed me about Jane’s reaction is she did not express a fear of sharing what amounts to a specification with the public that might fall into a competitor’s hands. Instead, she focused right on the logistics of how this could be accomplished. She felt that even a carefully selected customer set would have trouble understanding the user stories. I agreed, but there were ways to make them more palatable. Here is a summary of what I suggested:

1. Carefully select the customers you want to invite to participate.
2. Share these in a social media site where this group can view, comment on and share their reactions in an open collaborative way with other respondents.
3. Unveil the user stories as supplements to a wireframing example of the flow of the solution, where the user storied are viewed as callouts on each window.
4. Have the site monitored 24/7 and aggressively respond to user comments, requests and suggestions. Show in an immediate of a way as possible, you value each customer’s participation.
5. Pay the most amount of attention to adopting terms that appear to have universal recognition amongst the customers providing that they do not loose any required specificity or meaning.

I asked her why she was not afraid of exposing this level of information. Her response was gratifyingly typical of what I see is the emerging psychology of the more successful organizations. Success is not gained by maintaining secrets, but rather by being open and having a superior execution capability. I remember years ago a manager once telling me they would never put information about their company on the internet because it just gave their competition access to free information. Today, you can find even your local pizza shop on the internet of course!

I warned Jane, she could expect some serious bumps in the road here, but that was the nature of the effort and the rewards far outweighed any of the pains this process would cause or exacerbate. One of the many benefits is it has a tendency to remove arguments about language from inside the team. With the users directly commenting on how well the function or feature is expressed and how much they value the capability, arguments and differing internal opinions can diminish drastically.

So why not take a bold, new step in beginning to crowd source your requirements from your customer base. If you adapt your process as you learn more, it is sure to be a clear success!