Which scrum actors should attend a requirements gathering session

Question

I'm currently having a debate with some of my business analysts as to whether the testers and developers from the scrum team assigned to a project should be involved in the requirements gathering meeting.

My viewpoint is that it is crucial that a developer is on hand to offer advice from a technical viewpoint and the tester is there to facilitate the development of acceptance criteria. Also, the team get to meet and build a relationship with the stakeholders and get to see hear the requirements discussion at first hand.

So, in summary, would you leave any of the following out of a user story session?

• Scrum Master
• Product Owner
• User
• Developer
• Tester

Personally, I think they all should be there.

Answer 1

Never... :)

By leaving the scrum team out of the conversation, you are just moving back into the pitfalls of waterfall requirements. When features are written in a vacuum, then you either end up with a feature that rarely meets the product managers or many back and forth documents as PM and Eng "negotiate" the feature.

You're also missing out on an incredible wealth of expertise if you leave out the people doing the work. If they understand the entire picture, they will often be able to provide a better solution to give the customer value. If you tell the developer, "put this button here so they can print" the developer will do just that. If you tell the developer "I want the user to be able to capture the results of this output" then they might point out that the majority of the user base is mobile and uses something like Evernote or Pocket and perhaps that is more important to support these solutions than printing which only works for 5% of the user base.

Enterprise Requirements Planning: When you start scaling beyond a handful of teams, it can be very hard to include everyone in the requirements building exercises. A hundred teams is close to a hundred people.

At this point we don't remove all these people, we just scale it not unlike a scrum of scrums. We call this the Product Owner Team. A POT has representatives from all the key areas.

• Product Owner
• Voice of the Customer: (may be the PO, may be someone in Biz or Sales)
• Architect: (Needs a strong technical and business sense)
• QA Architect: (a senior QA person who has expertise in total development cycle)
• Developer Rep: (someone who could do the actual coding for this area of the product) Customer Service: These people have an incredible sense of how the customer uses the product. Use them. Operations: You need to deploy this product. Knowing in advance how that will happen and challenges can lead to better architecture up front.

Answer 2

My point of view is a little bit different, that have been sound here.

First of all, I strongly believe, that it depends.

We do this as follows: Product Owner has conversation with Stakeholders and gathers business requirements from them (he represents these requirements as User Stories). Then he goes to Development Team and discusses with them these requirements. Development Team gives rough estimation and asks some clarifying questions (if it has them) about requirements. Then Product Owner brings these questions and rough estimate to Stakeholders...and so on. This is continuous and iterative process. It is my understanding of Product Backlog Refinement (Scrum term). Only well refined Product Backlog Item can be taken in Sprint.

Maybe it is better not to use Product Owner as proxy and let Development Team to contact with Stakeholders directly (I asked similar question here)? Maybe, but not always.

In my last project we tried to implement this case. We sent one developer as technical consultant with Product Owner to meetings with customer. But we stopped to do it after two or three mouth (I don't counted exactly). Reason for this is that it was enough 15 minutes to him to discuss all technical questions, and rest 2 hours he was boring and cannot provide any help with business details. Well, it's logical, he is excellent programmer, not business-analyst. Also, he couldn't provide estimation, because estimation is responsibility of whole Development Team.

So, yes, members of Development Team participates in Refinement (including clarification) of Product Backlog Items (requirements), but not directly (through Product Owner). And of course, they are not that guys, who generate requirements.

I thing this situation happened because we have specific area of development (we develop or customise software system for needs of other companies, and our team and projects of our team are not too big: 12 members in Scrum Team - this is maximum of projects where I participate as Scrum Master). If you developing Enterprise solution, than Joel's approach may be better.

So... As I have said in the beginning, there is no right answer for this question, because it depends on many factors.

Answer 3

So I'm hearing that the real problems are that during the requirements gathering meeting you want:

• good AC developed and
• you want technical guidance to balance the feasibility of the business requirement

If this is the goal of the requirements gathering meeting then...

Both of these can certainly be achieved by including a technical and/or testing representative. However, there is no yes/no answer if this is the correct decision for your team.

I've worked with a multitude of BA's that are savy enough to understand technical implications and write good AC. I've also worked with BA's that care purely about capturing what the customer wants and often provide bridge-to-knowwhere requirements.

I'd consider your problem via cost benefit: Is it more effective/efficient to include a tester and a developer or are there other ways that achieve the same results that are less wasteful?

Consider the timeframe of the project and the maturity goals of the team in your decision as well.