Developers Don't Care That Your Issue Is Critical
21 Jul 2015All too often, I sit in a meeting with a client and conversation goes a lot like this.
Me: “Okay, looks like we have 4 features fully fleshed out here. When do you need each of these by.”
Client: “We need these yesterday”
Ah yes, the old “We need these yesterday” shtick that business people love to use. I’ve never fully understood this. I’m not some kind of future-altering time-lord. I can’t just fire up the flux-capacitor and make my dev team hit 88 mph just as much as you don’t have a magic ball that can see into the future. You made some mistakes and now there is a bucket of functionality that you need NOW. I get it. I can empathize.
However, what people often don’t realize is that dictating everything as critical can be more harmful than you think. I can recall one project in specific where I had 8 large features in the pipeline and they had the following levels of criticality:
- Critical
- Important
- Requires Immediate Attention
Developers were scrambling trying to figure out what needed to be worked on next. We had to sync up with our Product Owner and ask what was most critical in that moment. The answer was often different depending on what time of day it was. We were awash in a world of fluctuating levels of importance that just resulted in everything seemingly having the same level of importance. That helps no-one and it hurts the app overall.
##Criticality vs Priority
What we settled on was a simple system where we ordered our features based on importance. Features of the top-most importance floated to the top of the stack. When a developer needed to move on to the next feature, a card would be popped off the stack and that was the work that was done. Just look at this:
- Users can sign up.
- Users can log in.
- Users can log out.
- Users can delete their accounts.
As a developer, it is simple to know what needs to be done first in this list. The first one. I don’t need to know the business reasons for why a user needs to be able to sign-up because that has already been thought out. The Product Owner has already thought through the flow of implementation and now I can focus on the actual implementation. I also don’t have to bother anyone with the question “What needs to be done next?” I just take an item off the top of the stack and go.
Now, sometimes I may move out of order. Sometime I am wrapping up my day at it is 4pm and I take the 3rd item in the list because it is a light feature and I know I can bang it out in a single hour. That is okay, so long as the next day I take the #1 item on the list.
This system of prioritization has proven extremely valuable. My team likes it so much that we eventually moved away from assigning criticality entirely. Criticality in inherent in a features when they are prioritized