I’m a big fan of the Evil Overload List. It is a list of handy suggestions of things not to do for anyone that wants to take over the world, such as “don’t monologue”. Many of tips aren’t just for evil overlords, but also are very applicable to software development. I believe the most important lesson from this list for anyone in software development is: If my advisors ask "Why are you risking everything on such a mad scheme?”, I will not proceed until I have a response that satisfies them.
I consider having a good user story to be the most import part of the development process. When requirements are handed to developers they must understand the value that will give the end users. They need to understand not only the solution that they are being asked to implement, but the problem end users are having and how that problem impacts their business. Digging into the reason behind each software change allows developers to better understand the job the end users are trying to accomplish, increases the developer’s domain knowledge, and allows them to become active participants in recommending alternate solutions.
I simply will not put up with bad user stories. I have to understand value behind any feature I’m asked to implement before I will attempt to code it. Some developers don’t do this, and frankly that scares me. Without a good user story there is a high potential for introducing inconsistencies into the system and bloat the code to the point that nobody understands how or why it works the way it does. This must be avoided for the health of the product.
If any developer feels the need to improve the user story, solution, or requirement they are presented with that developer needs to be empowered, nay encouraged, to ask whatever questions are necessary to improve that user story.
If there is a bad user story I will investigate further until I am satisfied that I know why we are doing what we are doing. Some people might get annoyed (or even offended) by me investigating (second-guessing) their solutions/requirements. They may think that I am just wasting time. They may try to squash the conversation, bypass the explanation phase, and try to get me to jump to the coding.
There are a few ways they try to get me coding. The most common is to ask if “can” implement their solution. They present it as a challenge and are looking for a simple yes or no answer. It’s a loaded question because they know their solution is possible to implement. My response is, “I can make a computer do anything I want it to. The real question is, should I?” This “can you” question sometimes comes in the form of asking the developer for an estimate of a predetermined solution instead of asking them if they think it is a good idea.
Another common way people try to bypass the user story is to quote the “customer (or boss) is always right” rule. Having a stance that the customer/boss is enlightened and it is somehow acceptable to keep developers in the dark is the very definition of mushroom management. Asking questions doesn’t imply that their requested solution is wrong; I’m just asking them to share their enlightenment.
I do understand the appeal of jumping to the solution. We praise the problem solver. They are treated as more virtuous that those that simply gripe about problems and offer no constructive solutions for them. Although being a problem solver will likely result in individual praise, there is no I in team. To build a good team and to be a good teacher you need to ask good questions. You need to let the team members at least have a chance to answer those questions before doing all the thinking for them.
OK, enough rant. So how can do you actual write a good user story? I cover that in my next post, Reason Based User Stories.