The ‘Stakeholder’ role in agile product development

The rise in digitalization has linked all existing departments to a tech division — specifically for this article — Product Teams. If you’re one of the people working around these teams, you might have noticed that they’re mostly using a different organization technique called agile. But after all, why does it matter for you? It’s how they organize, not you. However, for your collaboration to be productive and for them to produce the most valuable results, there are a couple of guidelines on how you can behave to make that possible. So let’s talk about your role in their system, what you can do and expect and what you can’t.

But let’s first define who you are:
Anyone who has stakes in an agile team’s development is called a ‘Stakeholder’. But, of course, no one from outside the company (ex: Governments) is going to care much about it, so this article focuses on internal stakeholders — the sales departments, marketing, all the C’s and V’s and other letters, the HR, the customer support, biz dev, all the departments in a company that make it run.

Their system (Scrum)

Scrum Wheel

I hope you have at least a basic understanding of how all this works. If not, stop here and go and watch this. I’ll wait 🙂.

Even if your tech teams don’t use Scrum, chances are they still use the elements we’re going to discuss. If they don’t, you have this internet stranger's permission to go and ask for this implementation 😊 — it’s probably going to help them most.

You’ll notice that they have:

• Roles -> PO/PM (Product Owner/Manager), Developers, and Scrum Master
• Events -> Planning, Daily, Review, Retrospective, Refinement
• Artifacts -> Product Backlog, Sprint Backlog, Increments(which I’ll call “work” from now on for simplicity)

I’m going to start with the parts where you have a role and finish with the elements that are just for them. I’ll also give you a 1pager with do’s and don’ts that you can print and keep nearby if you want 🖼.

1. Stakeholder’s Role in the Product Backlog

Stakeholders play a crucial role in shaping the product. That input is usually collected in the product backlog. The backlog itself has a keeper, and that’s why your first job is:

a) Continuous collaboration with the Product Owner (called Manager sometimes) — PO

by Nataliia Iurchenko

This person:

• Is the voice of the stakeholders inside the team (that’s you);
• Represents their team;
• Manages your and the teams' expectations in terms of what will be developed;
• Creates and manages the delivery timeline;
• Creates and manages the backlog;
• Prioritizes the work that the team will do;
• Pursues the vision of the product;
• Represents the customer needs in their team.

Basically, the only thing they don’t do is read minds. Because of this and all their actual responsibilities, they are the perfect person to keep in touch with. If you have input or want information about any of these subjects, the Product Owner is your person.

b) Share Feedback and Ideas

Source: https://edinburghagile.com/sketchy-guides/the-sketchy-guide-to-scrum/

Agile teams rely on feedback from you and customers. Unlike classical product development (waterfall)— where business defines the product up-front, and then it just gets developed — agile development is iterative, meaning that: Without stakeholder & customer feedback along the way, they won’t know which direction to continue. So please, share feedback and ideas — either from your own experience or the experiences of your own stakeholders (ex: suppliers, shareholders, customers, etc.).

Things you can share:

• Things that worked well — We all love to be praised;
• Problems that you or them might encounter — The job of a product is to solve problems. The product teams need to know the existing or future problems to be able to solve them;
• Ideas — Just be aware that sharing an idea doesn’t mean it will get implemented (a product backlog can be endless for a reason 😉).

Things you can request:

• To negotiate and agree on timelines — You can discuss with the PO the current timeline expectations and negotiate scope to change them;
• To negotiate and agree on priorities — Same as above, be aware that not everything can be a priority; otherwise, nothing is a priority.

c) Understand how Agile Teams commit to delivering ideas

First of all, teams need to assess (with your help) the following properties of an idea:

The 3 risks product teams need to assess before delivering an idea

• Viability — Is this idea going to work for your business? (will it make a profit?)
• Desirability — Is this idea solving a real user problem, making it desirable for users? (will anyone buy/use it?)
• Feasibility — Can we build this? (do we have the skills & resources to build this idea?)

Agile teams assess these risks with the help of stakeholders and different experimentation techniques. If the ideas aren’t profitable, valuable, and/or easy, they will not be implemented first (they might still get implemented after everything else).

d) When else can ideas be rejected?

cumulated poll results from ~50 stakeholders

While running this article as a workshop, I’ve noticed that there are some misconceptions regarding when teams can reject ideas, so let’s address them:

1. Ideas that come from HiPPOs(highest paid person’s opinion) aren’t inherently bad! They just shouldn’t be directly considered good and instead be validated like any other idea.
2. Engineers disagree with implementing an idea for a reason — it’s not feasible. This idea is probably way too hard to implement for the value it adds, or it will create too much technical debt, or requires an outdated technology, or one that is not developed enough yet, or so many other reasons. They are experts in product development. That’s what they’re paid to do, so listen to them.
3. Just because an idea is big doesn’t mean that the team shouldn't do it. All game-changing ideas are big. There are whole industries where you only need big ideas. Indeed, agile development works in increments, so the team might not deliver the whole idea from the beginning. Instead, they will break it down into smaller valuable increments. That does not mean that teams will say no to something just because it’s too big initially.

2. Stakeholder’s role in the Refinement

If you’re a subject expert on a topic the agile team is working on, we don’t need to play cordless phone, instead, join the refinement and explain it directly to the engineers.

You’ll be able to answer questions better than someone else.

3. Stakeholder’s Role in Sprint Review

Facebook reactions

As a stakeholder, your main job in the Sprint Review is to react to what is being shown. Here you can:

• See the new developments first hand and understand all aspects of the implementation directly from the source.
• Provide feedback to the entire team about how these new developments work for you - and even suggest improvements. This feedback is extremely relevant and influences the next sprint backlog.
• Understand where the development plan is and what will happen next.

4. Stakeholders and Scrum Masters

Scrum Masters or Agile Coaches can help you understand “the ways of the agile”.
Feel free to talk to them anytime you want to understand the agile methodologies.
Be open when they approach you to discuss impediments the teams might face where you can help.

In most cases, agile applies to other types of departments as well, not just tech. So if you’re tempted to try it, they are also your go-to person.

5. Where do Stakeholders not have a role?

a) Planning & Sprint Backlog — you can only give input. It’s the responsibility of the agile team to decide what gets developed now. They also need to make their priorities transparent.

b) Developers & Daily —During the sprint, there should be minimum stakeholder input to the team. Instead, reach out to the PO. Here are some exceptions:

• Your review is required for work in the sprint → A developer will approach you for it. Please be mindful of their time, they commit to the sprint goal, and without your input, they might not reach it.
• You have a question about how something works → Usually, a message to the entire team is enough. They can then self-organize how to respond to you. (In some cases, the PO is the right person for this as well, this isn’t a one for all policy)
• You found a bug → Same as above.
• You need the team to do something → Nope, go to the PO. The development team prioritizes its tasks harshly(as discussed above), and small distractions can lead to critical value for the company not being delivered.

c)Retrospectives — this is the space for the team to inspect their own processes and improve on them and their collaboration.
In some cases, if you’re working closely with the agile team, you might do occasional retrospectives together so that you look at your collaboration and improve there.
Quick-tip: You can run retrospectives for any team, so consider adopting this practice in your department as well (Agile Coaches & Scrum Masters can help you).

6. The 1-pager I promised you, feel free to comment on some other tips I might have missed