As developers we’re constantly inundated with requests like this ….
- Can you add a button that does does ________
- On this screen _________ I need to have a chart of ________ displaying data …
- I need a report that shows me _________
- Can we add _______ to this page?
- It shouldn’t be too hard to add this, its just a field on the screen …. (then they explain what its supposed to do)…
(classic scope creep)
Prioritization
The order in which a developer prioritizes items in their “todo” list is often determined by the urgency placed on them by their direct managers (or higher ups). More often than not we find a high level executive or decision maker wants a feature implemented because they “think” it will add value to the product. Again, more often than not, the executives theory of how this feature is a viable request has no data to back it up. Therefore a feature is implemented with no verification that its a needed or requested feature. Please remember, this doesn’t always fall upon the shoulders of the decision makers… as developers we’re enamored with making things sparkly and shiny. If we think of a cool new “hot key” that we can add to our app, we’ll do it, even though it might take four hours to implement, we’re confident it will be the feature that saves the world.
Uhhhhh, Nope. Afraid not McFly.
What’s the root of the issue?
We need to ask ourselves a simple question….
Question: Is this feature a vitamin or is it a prescription?
Before we can answer this… lets look at some simple definitions…
Vitamin – A supplement that helps you, its good for you, its nice to have, but its not required.
Prescription – Medicine that helps you. Its required, it helps you survive.
Answer: It depends. (the classic developer answer… well… it depends… ๐ )
The Process of the Request
When an feature request comes in you need to ask (as well as the client who requested it) …
Is this feature/request a Vitamin or a Prescription?
This is the same as asking…
Is this feature request a “nice to have” or a “requirement to survive”?
This is going to determine if the request is worth putting into the system immediately. If you have 10 tasks, ask this question ten times and you might some up with something that looks like this:
(This mimics a fake Online Order Management system – for example purposes)
As you can see, we see that everything on the LEFT is a requirement for the system “requirement to survive” (prescription). Everything on the right is a “nice to have” (vitamin).
We may need graphs of data, but we don’t need 3-d graphs. We may need Web Access to the Order Management System, but we don’t need a Silverlight implementation to get this project to work. It would be “nice to have” a Silverlight implementation, but its not required.
Conclusion
The next time you’re asked to implement a feature, ask yourself…
Is this a vitamin or a prescription? Then put it in that bucket. Then, once that’s figured out, go into the prescription bucket and prioritize those upon business requirements. Then, when you’ve taken all of your prescriptions (all of those items are complete), ask yourself if the “vitamins” are going to add value to the project. if they are, then ask that question again (is this a vitamin or a prescription).
This ultimately comes down to an agile type of development process. We should only be implementing the things that add value and that are required for the app to serve its purpose. Most of the time a lot of these “Vitamins” will never make it into the system because its just not cost effective or necessary. Eventually some vitamins will make it into the system and sometimes its these Vitamins that make your system a step above the other systems, but this cannot be established until you’ve taken all of your prescriptions. If you’re sick and bed-ridden, you can’t take muscle vitamin supplements to get muscles big. You have to take the prescription to get well, then you can take the muscle supplements to get muscular.
Next time you get ready to implement a feature/request – ask yourself …
Is this a Vitamin, or a Prescription?
haha says
replica designer bags I recommend the package
replica designer handbags Of inexpensive package
air max 2012 Comfortable shoes
nike shox turbo Cheap shoes
men puma shoes Unique design Shoes
air max 90 Variety of shoe styles
wholesale puma shoes Pretty shoes
puma shoes sale Cheap comfortable shoes
timberland mens bootsย Discount a lot of
gucci women shoes Quite well shoes
louis vuitton outlet Very nice