All the best!

A good luck “brasa” (Surinamese for “hug”)

What I see in your post is that you define the role ‘developer’. I think you should always try to focus on user roles. It is obvious a developer wants to have a lot of things but the concept is user and functionality orientated. Most of the time you can rewrite a ‘developer’ user story to a real ‘user’ user story.

Depending on the type of project it is an idea to write down some user stories before the meeting starts. This can give the client more understanding of what is expected, especially if it is the first meeting they attend. We always define the ‘features’ / ‘epics’ first (they are most of the time state din the quotation) and then together with the client we define the stories for each ‘feature’ / ‘epic’. The benefit is that you can keep the focus on the original scope. this is important since I in our lien of business it is possible that the user story meeting is not always with person who signed and negotiated the contract.

At Us Media we do the User Story meeting together with the client, the planning poker session with the develop team and the prioritizing meeting we invite the client again. It is important to do the poker session before you start to prioritize since you can only give value to a story if you know how much work it is expected to be.

During the meeting I think a whiteboard/flip-over is very useful. Sometimes you end up in such a meeting with a discussion that can really eat away your available time. In such a case the flip-over can help to note down the issue (park it on the flip-over) to get solved at a later time (maybe internally by the client).

We use static paper that we stick on the wall (you need a flat wall for this) then we write the user stories on index cards (not post-its) and stick these cards to the static paper, works like a charm. If you cannot use static paper a billboard will also work very good.

Well hope this helps you in these first steps. I’m looking forward to future posts and experiences.