Step 1: Interview to Identify Tasks

As with all development we are trying to provide our customers with a piece of software which, based on our best interpretation of the customer’s needs, provides a solution to the problems or opportunities that lie in their path.

The primary way to provide our customer’s with an accurate interpretation is to actually listen to them when they are telling us what they need. This can best be accomplished via one on one interaction while recording their needs.

It is through these interviews that we can begin to identify and recording the individual tasks which are involved in completing the system transaction which the use case describes.

Step 2: Ponder & Ask Questions

Once the tasks have been captured some time needs to be taken to actually review them. By analyzing the tasks we can often find incongruent or missing tasks which need to be clarified or added by the customer.

All questions which arise from the review should be presented to the customer for clarification, explanation, or validation. This should be done in person to increase effectiveness.

Step 3: Identify All Inputs and Outputs

Although the tasks may be clear prior to this step the inputs and outputs involved in those tasks may not be. In this day and age where information (data + context) is extremely valuable and ever present almost every transaction a system processes either consumes or produces information, often times both.

It is vital that customer’s are queried in regards to each task in the transaction in an attempt to identify all inputs and outputs so they can be properly identified in the description. Failure to do so can have severe consequences in development.

Step 4: Look for Patterns

It is not uncommon for multiple transactions within a system to share repetitive tasks or for specific tasks to repeat within a transaction. These repetitive tasks can often be identified via iteration or looping patterns. It is important that these patterns be identified in the description in order to avoid duplication of effort when in development.

Step 5: Verification

The final use case description should be verified by the customer. Since all descriptions should be both readable and understandable by anyone the customer should be able to read through the description and immediately provide feedback as to whether or not the transaction and its associated tasks described within the use case actually fits their understanding of the transaction in reality.

Step 6: Sign Off

Some may argue this step is a bit too much but if you have ever dealt with fickle customers who always seem to forget that they agreed or approved something this step can be a lifesaver in the long run.

Although all customers forget, there are different degrees and different types of forgetfulness. The ones I am pinpointing here are those that have suddenly had a change of heart or want or suddenly realize that what they thought they wanted isn’t really what they wanted and decide that they should forget that they approved a user story for development. Normally this would be fine but when everyone has agreed upon a sprint backlog and a delivery date this forgetfulness can cause some real trouble for the developers, analysts, and project managers.

To mitigate this I prefer that the client, after verifying the user story, sign and date each user story in blood (ok not blood, ink will do). This not only makes things official but forces the customer to really think about the user story before signing. This hesitation is due to the fact that people value their name and are rarely ok with placing their name on garbage.

Conclusion

A little extra effort upfront saves factors of effort at the end.

Sources/References