For the purposes of this article, I’m going to rename 'stakeholder management' to ‘stakeholder success’. We want our stakeholders to win alongside us, after all, and not to make them feel like something to be 'managed'.
Now I’m a big advocate of Scrum. It’s sometimes given a bad rap but I feel this usually comes from folks who misunderstand it and follow every Scrum anti-pattern known to mankind. Scrum is very clear on how to build and launch software, but I feel that most teams disregard a key value from the Agile Manifesto when adopting Scrum:
“Individuals and interactions over processes and tools”
This value isn’t just referring to the Scrum team (e.g. Product Owner / Manager, Developers, etc). It’s also referring to the various internal and external stakeholders who need to win alongside you for the product to truly be a success.
So how and when do we engage with these stakeholders as part of Scrum-based delivery? Let’s find out…
Please note: I use the term ‘Product Manager’ throughout the article, however this can be a Product Owner / Product Lead / whatever Product role where the person works directly with the Scrum team to deliver product increments (i.e. some functionality developed and ideally launched as part of a Sprint, which provides some value to an end-user).
Discovery / Envisioning
Discovery (often called ‘envisioning’ in Scrum circles) is where stakeholders are first engaged. In fact, I’d say this is where you ought to identify said stakeholders in the first place, especially if you’re building a new product.
Without going into detail on how to run your discovery work, make sure you use the opportunity to identify:
- who your non-customer external stakeholders might be e.g. regulatory bodies
- who your internal stakeholders might be
Now go out and validate those assumptions. Speak to these stakeholders and understand how they want to be involved. Ask them if they know of anyone else who should be involved. Speak to them too.
Map your internal and external stakeholders into a RACI matrix and / or power-interest grid.
Let’s say you’ve identified your stakeholders and how they want to be involved with the product development process. For example, do they want to be consulted? Are they happy with just being informed?
Once you’ve identified this, get them involved as appropriate during the rest of the discovery process as you learn from customers & data, map out your product vision, lean canvas, value proposition canvas, backlog definition, what-have-you.
Ultimately, if you’re leading on product delivery and you are appropriately empowered, you ought to be making the final call on what makes it through to the backlog. But make sure your stakeholders feel heard.
Release Planning
Once you’ve created an appropriately DEEP Product Backlog, you can kick off Release Planning. Most stakeholders are only interested in one thing here - what features will be delivered for this release, and by when?
Whether you have a seasoned team who’ve done multiple releases before and can do some fairly accurate release planning based on historical delivery data, or you have a new team with no historical delivery data at all, make sure you set your stakeholders expectations accordingly so they know not to expect to be able to fly to the moon in 6 sprints.
Remember that release planning never really ends. Every plan needs to adapt as you learn new stuff. When this happens, don’t forget to communicate these changes to stakeholders - whether that’s through your Sprint Reviews / Demos, or ad-hoc meetings (the latter may be needed if it’s a drastic change and you know an influential stakeholder has been desperately yearning for that feature).
Sprint Planning
Don’t get other stakeholders involved here. Stick with the Scrum team.
However…once you’ve landed on a Sprint Goal, and the team has identified and committed to what stories will be delivered to achieve that Sprint Goal, then make sure to communicate this to your stakeholders. This sets their expectations accordingly for what to expect at the Sprint Review.
Backlog Refinement
Stakeholders who can provide valuable information on certain stories or epics are more than welcome at Backlog Refinement / Grooming sessions (‘grooming’ is such a weird word, isn’t it - I’ll stick with refinement).
The Product Manager may be the voice of the customer and all stakeholders, but it’s nigh-on impossible for them to know everything about a topic that may be more closely-aligned with another stakeholder’s expertise. For example, if you’re building a feature that has a heavy psychology angle - bring in your resident psychologist stakeholder to provide more context to help the team refine the story. If your feature has a heavy marketing angle, bring in your marketing manager or CMO.
This is a great way to engage stakeholders, help them feel heard, whilst giving your team valuable insights which can help them deliver a product increment that’s highly aligned to the original intent. Win win all-round.
Sprint Reviews
Probably the most obvious place to rope in your stakeholders. My temptation has always been to invite anyone and everyone. Essentially anyone who has a vested interest in your product should be involved.
Sprint Reviews / Demos are a great way of building your stakeholders’ confidence in you and the team. No pressure, but personally I’m an advocate of making sure you have a full product increment ready to show to stakeholders every single sprint. It doesn’t have to be anything fancy, but if you’ve set stakeholder expectations accordingly by communicating the Sprint Goal at the beginning of the sprint, then make sure you’re able to show that you’ve delivered against this goal.
Of course, if you’re unlikely to meet the Sprint Goal, see if you can signpost this to the most pertinent stakeholders in advance of the Sprint Review. Be transparent. Describe what you’ve been able to accomplish instead. However, make sure to take this to the Retrospective afterwards to learn from it, as you don’t want to get into the habit of not delivering versus agreed Sprint Goals.
Sprint Retrospectives
These are usually just for the Scrum team, especially as a key principle for this ceremony is that everyone feels safe to express themselves.
However, it’s also important to have people attend who can enact some of the changes that certain learnings may call for. Usually the Tech Lead, Design Lead, Product Manager and (if you’re sufficiently blessed enough to have one) Scrum Master should have the power to make the changes required. But if 'lessons learned' are likely to arise around Marketing, Sales, Customer Success etc…it may be worth bringing one of them in, as long as it doesn’t jeopardise the team’s feeling of psychological safety and won’t harm the relationship the team has with that stakeholder.
The entire organisation needs to foster a learning culture, and this is one way of doing it.
Artefacts for stakeholder engagement
So far I’ve described how you can engage stakeholders as part of Scrum ceremonies or processes. However you shouldn’t just rely on these to engage your stakeholders.
Use your product artefacts to make sure your stakeholders have a single source of truth to refer to should they have any questions.
For example:
- An appropriately refined Product Backlog is perfect for stakeholders to refer to when they want to understand the relative prioritisation of work and what each story entails
- A Release Plan (not an official Scrum artefact) is useful when your stakeholders want to understand what will be released and when in the near-term
- A burndown chart (not an official Scrum artefact) is a great way of keeping your stakeholders aware of progress without them needing to pester you for a status update
- A Product Roadmap (not an official Scrum artefact) is probably the most sought-after artefact for stakeholders to understand a much longer-term view of what we’re aiming to deliver over the next year or so, how it’s currently prioritised, and so on (you can also have different versions of your Roadmap for different types of stakeholders to fit their specific needs FYI)
In summary
Using a combination of Scrum ceremonies and product artefacts, you can bring your stakeholders along for the ride to deliver something delightful for your end-users / customers. I highly recommend that you maintain some rigour towards enabling stakeholder success - it’s not an area where you can just ‘wing it’.
Also, petition to replace the term ‘stakeholder management’ with ‘stakeholder success’? ;)
Have fun!