We are working with a corporate partner, who is providing us detailed requirements for changes to their customer documents. They supply the text, we apply it to the document and get it tested. During the planning workshop for our last timebox, the conversation got interesting :
Business Ambassador: “We may not get the final text for that document in time.”
Project Manager : “How much of a problem is that?”
Amb : “Well, if they don’t get it to us in time, we can’t complete it, can we?”
PM : “So, we can call that a Should Have…?”
Amb : “Err.. no. I’m not going back to them telling them this isn’t a Must Have”
PM : “But by definition it isn’t. We wouldn’t stop or delay the project if we didn’t deliver this, would we?”
Amb: “No, but if they do send us the text in time, we have to deliver it. So it’s a Must. If it’s not a Must, it won’t get delivered.”
PM : “That’s not true!”
The story was marked as a Must, but it made me think. Strictly speaking, that story was by definition, a Should. But the Ambassador wouldn’t accept that because thus far, our focus has been almost exclusively on the Must Have stories, and little else gets delivered.
The point he’s missing, though, is that the statement “If it’s not a Must, it won’t get delivered” becomes a self-fulfilling prophecy. The greater the portion of your requirements prioritised as Must Have, the less chance that you’ll be able to work on anything else.
This story was also a Must Have only if the partner provided the text that comprised the detailed requirements in time for the team to code it up and get it tested. A conditional Must Have requirement in other words. Awkward.