Over the past few years, I would ask Product Managers or Business Analysts to send me some sample requirements so I could help out some new people on our team with how to write requirements. If they were using Agile, I’d sometimes get back a response akin to – “Oh we don’t do requirements, we write notes” or “Yeah, I don’t have anything to send you because we don’t have documents on any of it.”
To which my response would be – “but how do you know what you are building?”
And the response to that would be – “Well, it’s Agile!”
Agile doesn’t say to write requirements, if anything it requires that much more clarity between the grand vision and then the micro-requirements (stories) that combine to form the greater view of what the entire requirement is. These are two very different views of what is being delivered.
If I break it down from the Product Manager’s perspective.
“I need a thing called X.”
“X has 7 pieces to it that we can’t do all at once.”
“Great can you do them in this order and show me progress as you go?”
“Yes, but can we switch up this order so the riskiest stuff is done first?”
“That makes sense, when will we be done?”
“Based on what I see, probably by Date Y, but I won’t be for sure until we get Piece 4, and then I will have greater certainty.”
“Great, what do you need me to do?”
“Document these as much as possible these 7 pieces so that we don’t miss anything.”
“But what if one affects the others and I can’t fully do it yet?”
“That’s okay, but that affects Date Y, so the goal is to minimize massive change when we get Piece 6.”
“Great let’s get started.”
In that scenario (very simple), we still have requirements, we have priority, we have predictability in what we are shipping, and we have the larger picture being delivered.
Requirements are at the core of what will be done to make it a success.
