11

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.

3 Answers 3

9

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.
3
  • This, x 1000. Find a way to get the team involved early and often. Aug 24, 2015 at 19:26
  • Right on Joel. Maybe I'll let the my business analysts read this ;) Aug 24, 2015 at 19:43
  • See my comment below in WBW's response. Awesome BAs are worth their weight in gold. They still can't replace the person with hands on keyboard experience. You need them both. Aug 25, 2015 at 16:50
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.

0

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.

5
  • Out of curiosity, how would you validate the effectiveness and results of including them or not including them? Aug 24, 2015 at 20:29
  • True, some BAs are tech savvy but I reckon the cost of putting a dev and a tester into a 3 - 4 hour meeting which precedes a 3 month development would save more in time than it would cost. Also, in my 26 year career, the biggest flops I've encountered resulted from the Chinese whispers that came from the BA's interpretation of what the PO originally wanted. The three Amigos can start as soon as you like on a project. Aug 25, 2015 at 5:09
  • I'd rephrase; putting a dev and a tester in a 3-4 hour meeting which precedes a 3 month development cycle may result in a better initial plan. The scenario described above has a low cost but it can also have a pretty low benefit over the duration of the project...It doesn't guarantee that what the team builds over the next 3 months will be what the customer needs or will be implemented in a sustainable way if the requirements or technical landscapes are subject to a lot of change.
    – WBW
    Aug 25, 2015 at 16:24
  • To Jeff's question, assuming you are using iterative methodologies during development taking AC for instance you could measure things like defect rate, story cycle time, PO acceptance/reject rate, customer CR rate or UAT feedback and correlate that to the strength of the AC. More qualitative measures could include customer satisfaction and gathering feedback from testers and developers on if clear AC contributed to a smoother work flow.
    – WBW
    Aug 25, 2015 at 16:29
  • Even with a highly technical BA I still advocate having at least one "hand on" coder involved. Unless your BA or Architect is actively coding, they will quickly get out of sync with the day to day challenges of the code. Having the developer who can say "the C library has been having performance issues, we probably need to look at that before ading new features" is something you can't get just from technical knowledge. Aug 25, 2015 at 16:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.