Stakeholders that are directly affected by the release or will use the release’s functionality will need to be involved in release planning.

Stakeholders that are directly affected by the release or will use the release’s functionality will need to be involved in release planning.

In an Agile project, a release plan answers the “what and when”, based on organizational vision, project needs and team capabilities. The constituency of a release is usually broader than the Agile team. Classically, the interested parties would be called stakeholders. In order to develop a release plan that serves the organization, the team needs to understand the breadth of the release’s stakeholders. A potential list of stakeholders can be broken into three categories:

Obvious:

  • Agile Team
    • Scrum Master
    • Product Owner
    • Delivery Team
    • Business Users
    • Customer(s)
  • Marketing (for projects related to the products or the delivery of products)
  • Sales (for projects related to the products or the delivery of products)
  • Manufacturing (for projects related to the products or the delivery of products)

Program Level

  • Program Manager
  • Representatives from Other Agile Teams

Less obvious

  • Outside experts
  • Vendors/External Partners
  • Regulators

The majority of titles on this list are probably obvious; stakeholders that are directly affected by the release or will use the release’s functionality will need to be involved in release planning. A release plan for an Agile project within a program should involve a wider sample from other Agile teams. In order to determine who should be involved, you need to understand the relationship between the individual projects.  Those that are less obvious are rarely included in developing a release plan, even though these stakeholders can contribute significantly to the projects requirements.

One mechanism I use to develop the list of roles to engage in Agile release planning is to begin with the project’s walking skeleton.  The walking skeleton is generated from Agile Story Mapping and can be used to identify the minimum viable product. Once you outline the initial story map and walking skeleton, review each of the functions in the skeleton and ask yourself the following questions:

  1. Who will use this function?
  2. Who will develop and test this code?
  3. If this function interfaces to other applications (software and hardware), who owns the other application?
  4. Who impacts how the function must work?

This list of names are the people that could be involved in developing a release plan. Even if all of the folks on the list can not be involved, the list will provide a starting point. When deciding who to invite, make sure you identify the thought leaders on the list and representatives from interfacing applications.