Yup, its BS. And Scrum is not Agile.

I hate the rigidity of so-called agile practitioners who tel you that there is one "twue" way of doing agile and that you must follow all the rules laid out in the holy scriptures of whichever 'agile' methodology they use. Its all BS.

Agile is about being agile.

Agile is about getting stuff done with a minimum of overhead. This doesn't mean "no documentation" as you usually end up documenting more in an agile role, you just get on with the documenting without having to plan a process for doing the documentation. Similarly with coding, testing and requirements capture. The only things that matter in an agile process are those that help you get your job done, quickly and efficiently without any BS.

So in this case, if putting user requirements in the cards helps you write, test, document and demonstrate the code that is needed... bloody put the damn requirements on the flipping card and give the 'scrum gurus' their P45s!

What does the rest of your dev team think? In a true agile methodology, if they all think requirements should be written up front without any 'user conversations' then that should be it, you do what the team thinks works best for them to do their work. If the team thinks that the user conversations are a good thing, then listen to them and understand why they think this and bring yourself into their way of working.

Yup, its BS. And Scrum is not Agile.

I hate the rigidity of so-called agile practitioners who tel you that there is one way of doing agile and that you must follow all the rules laid out in the holy scriptures of whichever 'agile' methodology they use. Its all BS.

Agile is about being agile.

Agile is about getting stuff done with a minimum of overhead. This doesn't mean "no documentation" as you usually end up documenting more in an agile role, you just get on with the documenting without having to plan a process for doing the documentation. Similarly with coding, testing and requirements capture. The only things that matter in an agile process are those that help you get your job done, quickly and efficiently without any BS.

So in this case, if putting user requirements in the cards helps you write, test, document and demonstrate the code that is needed... put the requirements on the card and tell the gurus that the team is always right.

What does the rest of your dev team think? In a true agile methodology, if they all think requirements should be written up front without any 'user conversations' then that should be it, you do what the team thinks works best for them to do their work. If the team thinks that the user conversations are a good thing, then listen to them and understand why they think this and bring yourself into their way of working.