Scrum: Who are the Key Stakeholders that Should be Attending Every Sprint Review?

The Scrum Guide requires that the Product Owner ensure that "key stakeholders" attend the Scrum Sprint Review, but who are these "key stakeholders"?

According to the Scrum Glossary, a stakeholder is "a person external to the Scrum Team with a specific interest in and knowledge of a product that is required for incremental discovery. Represented by the Product Owner and actively engaged with the Scrum Team at Sprint Review."

Typically, they fall into one of three broad categories:

• The Users - The human people who actually use(^1) the software product under development, to help them or the organization make more money or save money.
   
  • This could include a human compliance officer within a company, who is responsible for making sure that the software systems comply with government or financial regulations.
  • This could include the humans who support the operations or production support for the product.
  • Upstream/Downstream systems could also be considered "users" so long as we don't forget the human end users of those systems. Don't forget the humans!
    • Downstream reports are a good example of a downstream system" where you should definitely not forget the "human end user", but there are other examples.
• The External Customers (doesn't exist for internal products -- see below) - The people responsible for paying to use the software product.
  • Only applies to externally sold or externally developed products
    • By external here, we mean, outside the company doing the development.
  • In a "software development for hire" arrangement(externally developed product), the client who engages the team would be the External Customer.
  • Sometimes the External Customers and Users are the same people -- take TurboTax as an example, or a software product whose human users also make the decision to purchase said product.


• The Internal Customers - The people responsible for making the funding decisions for the software product development effort.
  
  
  • This is usually someone in Product Management(usually for external products) or someone in management in the Line of Business(usually for internal products) that is supported by the software product.
  
  
  • It could also be the CEO or CIO or similar roles at times 


• There are probably exceptions to the above three broad categories. Also, don't assume that the Product Owner can only consider "key stakeholders" as sources for requirements or good ideas. The Product Owner can work with anyone any time (possibly during Product Backlog Refinement and other activities) who can supply good ideas to capture more value for the product. Our discussion of key stakeholders here is just to understand how the "stakeholder" role in the Scrum Guide can be interpreted.

The key stakeholders are the people that receive a direct financial(^2) benefit(helps them or the organization make more money or save money) from using the software.

One could also think of the management of the development organization as a stakeholder who should attend Sprint Reviews, certainly in replacement of any and all status reports and any and all other progress reporting for the Scrum Teams. If any Dev management asks for these things, the answer should almost always be something like "In Scrum, that information is communicated in Sprint Reviews, so let me get you on the invite list for that." For Scrum "key stakeholder" purposes though, I'm not sure I'd call Dev management "key stakeholders." or think of them as being "required" to be present(unless of course, they request status/progress reports).

In some cases, you'll have so many "users" that it is not possible to have all of them in your Sprint Reviews. In those cases, try to get a representative sample of human users into your Sprint reviews(some companies pay for this kind of feedback from human users), and also utilize other feedback gathering mechanisms. 

Parting Words

I'm sure that there are exceptions to the above three broad categories, so feel free to let me know if you can think of some noteworthy ones, or maybe see if you can effectively place them under one of the three broad categories above. Talk to the Product Owner and make sure that they are ensuring that key stakeholders are are attending your Sprint Reviews, as their input is absolutely vital to the success of the product.

----------

Notes:

^1 Rare exception -- note that sometimes a software development team acts as a "Production Support Engineer" user, but this should only apply to features actually in the product(support logging might be a good example) that help with production support. However, the modeling of a human user who is on the software development team should not become a guise for so-called "technical stories" or technical practices. That's not a real "user".

^2 Rare exception -- If the organization developing the software is a non profit, government entity, or charity, then instead of "financial benefit" or "money", we might say "the societal benefit" instead.