"A man who procrastinates in his choosing will inevitably have his choice made for him by circumstance."
-Hunter S Thompson
So I was thinking the other day about tech debit - Where does it come from and how do we wind up with so much of it?
so some of the scenarios that might ring (alarm?) bells are when you start finding extra details that need doing to get a piece of functionality to work and someone yells "Put it on the tech debit" or when all the Yack Shaving you are doing to get a story in is dumped on to the tech debit back log "For tracking"
Now I don't agree with this tactic and I'll tell you why - How much business functionality are you putting on a backlog that the product owner DOESNT PRIORITISE ??
Think about that for a bit while I try and disguise what I am doing enough to give you a concrete example.
Lets say you have a down stream system that is handling your orders for example - Now the guys building that system are behind you so you stub out the functionality and it looks good - What do you do with the integration piece? what does THAT user story look like?
"As a down stream system I want to communicate to a live up stream system so I can *Do some stuff*"
OK This sounds like a tech debit story - The user doesn't really care about integration so we shouldn't bug them with it right?
Or hang on a second - What if we never did this ?? Then our down stream functionality is utterly useless - It is the proverbial lipstick on the chicken.
Suddenly it is starting to sound like our business user *Might* care about this story - But when you start saying "Upstream, Downstream, Integration etc ……… oh my god! I just bored myself!! Your product owner is unlikely to react much better. So what IS the business benefit of this piece of work.
"As a business user I want my interface to book on to a live system so I DONT LOOK LIKE AN ASS WHEN I BOOK Y AND NOTHING HAPPENS !!!!!"
You may want to taylor the "so that" clause a little but the sentiment is there - The business value of the application *Actually doing something* is, I think, pretty clear. So I suggest the following - When you are next confronted with a bunch of tech debit stories that you are trying to shoe horn into a sprint around the eye candy your product owner is busily trying to prioritise (Ohh shiny!!) maybe see what the actual user story is? Start by thinking "if I never did this what would the end user experience? and would that experience result in no change to me or my p45 on my desk tomorrow?"&n
If the answer is the P45 better re couch it in terms your product owner understands
Nobody likes to see another unemployed IT professional :-)