‘Software requirements die slowly in Jira’, a head turning phrase I heard from another BA recently.
A bumper sticker slogan with serious potential, but I wasn’t sure I fully agreed with the sentiment. So I inquired further.
‘Arguably, the most interesting time in any software requirements work is the lead up to actually writing them down. I love the hunt and chase of this’, they clarified.
‘It’s not that Jira swallows up requirements, extinguishing all hope of them seeing the pasture lands of production’, they continued, ‘but starting to write them down signals the end of the creative process’.
I understood, and agreed.
‘The messiness of uncovering what the actual needs are, along with the fun of conversations and napkin sketches, has ended, leaving the hard work of making it happen’.
I understood, but I couldn’t agree this time.
Whilst they enjoyed the chase of corralling stakeholders and getting actual agreement on things, I’ve always enjoyed the challenge of building something tangible, aka ‘the hard work’.
The conversation did solidify something else for me, that is ‘the closer a (non-technical) BA gets to software requirements, the further they are from analysis and understanding needs, and the bigger the big red warning flag should be’. 🚩
I did disagree about one other thing, however. ‘starting to write them [software requirements] down signals the end of the creative process’. Maybe in their team, but certainly not in mine.
That’s why I’m a Technical BA, not an IIBA BA.