Defining Requirement Types: Traditional vs. Use Cases vs. User Stories | TechWell

Defining Requirement Types: Traditional vs. Use Cases vs. User Stories | TechWell:

'via Blog this'

This is a great article and substantiates my thoughts that corporate IT is not capable of rigorous SW development methodologies.

I have a purple carrot (var. atrorubens) in front of me. This epitomises the SDLC for SW engineering; it is as expected, uncomplicated and readily available. It is considered the norm since the dawn of time, or at least carrot recorded history ( <900BC). Having developed and tested telecomms and OS SW for years with detailed specifications covering protocols, standardised user interfaces and messaging systems, it seems common sense to me that systems should be clearly specified in a business benefit, then technical manner.

However, over time, once the introduction of fashionable orange carrots (var. sativus) appear around C18 the appearance of a purple carrot seems unpalatable for most customers.

This is Agile.

Having come across countless end users and business representatives, who apparently are the gatekeepers to an application go-live, and have no accumen in the definition of business requirements, it makes perfect sense that corporate IT has lent towards the advantages that Agile affords; an approach that advocates regular consultation with a customer that hasn't got the time, notion or training to deal with detailed requirements.

This might seem harsh, but so many projects have proven just that; the end user representatives are both the ones most qualified to determine if the new system changes are congruent with the proposed business changes, but also the least capable to dealing with detailed business and functional requirements. They don't like purple carrots.

Ideally, the business, or end user representatives want orange carrots; they were eating something else nice and tasty for ages, and while the new fangled carrots were interesting, it was only until they became mainstream (read IT systems delivering something useful) that they became useful.

The business wants orange carrots; no BPMN, no UML, in fact, no detailed specs. We can sort out what it's meant to do once you've built it. Agile is for the IT illiterate end user.

This shouldn't be seen as a shortcoming, but rather as a take on how Agile must be used by IT staff to engage the business.

The business DO NOT CARE how nicely your UML diagram looks; they don't have the time nor inclination to understand it. It isn't outlined how they would do it (a quote from someone not 3 months ago), they don't have time to read the specifications anyway, and do the BAs really understand what we need?!

So, if your business stakeholders are not SW engineers, erm, don't treat them like SW Engineers. SW Engineers like the thought of purple carrots, as it reminds them of vi. The business wants something they can eat now, so give them microwaved carrots.