Should developers be talking to users during Story planning / refinement?

Question

When you have a Product Owner who is less technical, can developers be brought into discovery with users and stakeholders?

e.g. A new project is underway and the PO is doing discovery, creating epics, user stories etc. However, the developers understand the technicalities better than the PO; should they be brought into the discussions with the users and stakeholders?

It sounds like it's not a good idea, but I have never really thought about it before and Mike Cohn doesn't really go into it in any of his literature.

Answer 1

Yes, ofcourse, why should the development team settle for second hand information. Self-organizing teams should get the information from the source!

I really like this item from the Cargo Cult Agile Checklist:

Stakeholders are prevented from talking to the Scrum teams

What are stakeholders? (quoted from Agile Modeling: Active stakeholder participation )

A stakeholder is anyone who is a direct user, indirect user, manager of users, senior manager, operations staff member, the "gold owner" who funds the project, support (help desk) staff member, auditors, your program/portfolio manager, developers working on other systems that integrate or interact with the one under development, or maintenance professionals potentially affected by the development and/or deployment of a software project.

So this means everyone is a Stakeholder. Engage them! But who to invite, all of them?

My current teams try to invite key stakeholders to our refinement and planning sessions to get the context from the source. Who is invited greatly depends on what topics we are handling. The Product Owner makes this call, the Scrum master makes sure the PO thinks about who to invite upfront. The stakeholders explain context, the development team asks questions.

Promote that the development team talk to as many stakeholders as they can. This to retrieve domain knowledge and understanding of how actual users use the product. Planning, review and refinement meetings are the ideal place for this as developers are already out of their (coding) zone.

Just try it and Inspect and Adapt after some sessions with PO, users and developers included. Ask them for their feedback or hold a specific retrospective to see what is working and what not for this type of discovery communication.

Answer 2

In certain situations I think they should, but there are a lot of caveats and gotchas to it. Let me list out reasons I have done it, and also times when I would not do it and maybe that will help as you consider what you need.

Before I start I want to echo Sarov though in that if your main reason for doing this is because the PO is not technical then some training should be done there to help his/her understanding. Regardless of any validity to the below reasons, that lack of experience/training should still be corrected over the long term. If requirements are your primary issue, I would have the scrum master assist the PO with writing requirements and explaining them to the team, and over time helping the PO to do that better. This is probably the main answer to your question but I am going to talk about dev involvement as I still think that could be valuable to you.

Reasons I have involved devs in discovery:

• I identified an issue where discovery was going very slowly, and there was a large problem where the business and the PO would get far to deep on their ideas and how they were going to be implemented, get emotionally invested, and then toss it over the wall to development. As part of my strategy to fix this I instituted a process where the entire product team was involved from day one to help guide the course of the product. This was not always attendance, but it was visibility to everyone. I did at first have a dev and a designer go to the main meetings, but as I had hoped as everyone got more used to working together and communicating this became less and less necessary as trust and respect was established and the PO became more versed in dev issues. Communication did continue even when there was no attendance, time needed from the dev was minimal, and the projects were ready faster, more on track, with higher dev buy-in.

• Another good reason I have involved devs early on, is that for some projects I have wanted them to hear the pain points first-hand from the customer's mouth. This does require a little bit of time for a dev, but again leads to much greater buy-in, and understanding of the issue the project is trying to solve. I have found that in many situations this leads to increased creativity and ingenuity on the dev's side, as they have a better understanding of the challenges to the customer. This leads to a better product than otherwise might be the case, which is one of the primary reasons for Agile, and is supported by these principles in the Agile Manifesto:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. -Emphasis added

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. -Emphasis added http://agilemanifesto.org/principles.html

• The last reason is an extension of the second one, in some cases I might want a higher level of communication between customers and developers during the project. By involving them early I am helping both sides establish trust and familiarity. The customer trusts that the developer(s) understand their problem, because they were there when they first explained it. The devs feel more comfortable asking the customers a question because they know who they are and where they are coming from. Again, this is something that needs great care, for it can be either very useful to getting the right product, or a waste of the developers time depending on the situation.

Long story short the main reasons to involve development are if it will help them build a better product. This must be analyzed on a project by project basis, and generally should be the decision of the team. If the project is small, or more internally based, or really high-level at first and a simple overview or meeting notes will convey the meaning, then I wouldn't worry about involving the devs.

Answer 3

Usually it is considered that developers can engage with users and stakeholders in the way you've asked as an exception rather than the rule.

---

Generic answer

You always have three roles:

1. Stakeholder who knows "what to do".
2. Developer who knows "how to do".
3. PO/BA in between who facilitates transformation of "what to do" into "how to do".

There is always someone in each of those hats. It might be one person who seats behind the screen writing new social network in three hats on top of each other. Or a huge company with departments walking around in one narrowly specialised hat each.

Going back to your question, how to actually make a decision "should developers be talking to users during discovery" or not? It depends solely on the goal you want to achieve, is it good for your goal or not. And I assume that the goal is the vision of organisation as a mechanism behind the product delivering it as a value in the most efficient way possible.

If current hats(roles) distribution across people is the same as it should be in your organisation - then you are doing everything right. But since person with PO title exists we can conclude that this very person is supposed to carry PO hat, and in reality cannot. Hats distribution seems to be wrong and the answer to your question in your situation is: no, they should not. (Or someone has a wrong title not matching real role.)

Also some examples when you want direct engagement not in the way you've asked:

1. Let people meet in person to become acquainted. It is more comfortable for us when we know real person behind username on the screen.
2. Let development team listen, to share the pain as Majaii mentioned already. We love to help and know about relief of actual person.
3. Let all project participants be gathered together and literally sit on one side while you present product/project changes and results.

---

Situational answer

Development team has nothing to do since PO as a bottleneck can't load the team. We can alleviate the bottleneck bypassing it and load development team from users directly. Should we do that?

Unfortunately this is where actual art of project management takes place. You need to consider all the risks, consequences and benefits both short and long term. Some of them are already mentioned in other answers.

---

P.S. Your question assumes, that stakeholders are somehow more technical than PO. Moreover, development team needs to obtain technical knowledge from stakeholders. This sounds very suspicious.

Answer 4

In theory you could, but that could result in a significant drain on the Developer due to time involved and task switching, especially if this is done in the middle of a Sprint.

What advantage would you be hoping to leverage from having developers present during discovery?

If it's so that the developers gain a better understanding of the requirements, then I would instead focus on improving your PO's ability to analyze and disseminate these to your developers.

If it's so that the stakeholders can get a better idea of what is feasible, this could probably be brought up during the Sprint Review, to which stakeholders can/should be invited.