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.