PMI Sites
Register
Disciplined Agile
Search

    Address Changing Stakeholder Needs

    This Construction phase process goal describes our approach to managing requirements changes. Changes may include new functionality, modifications to existing functionality, or potential defects in existing functionality. Of course, new information isn’t always a requirement change. The reality is that as a team works on something, the stakeholder’s understanding, and in turn the team’s understanding, of the true requirements will evolve and new or changed details will surface.

    2021 Project Management Institute Address Changing Stakeholder Needs v5.2 Stakeholder Interaction With Team Active stakeholder participation On-site customer Indirectly via product owner Indirectly via business analyst Indirectly via product manager Indirectly via digital means Change control board (CCB) Elicit Requirements All-hands demos Interviews Iteration demos Just-in-time (JIT) model storming Look-ahead modeling/backlog refinement On-demand demos Explore Stakeholder Needs Active stakeholder participation/on-site customer Agile Modeling session/big room planning Behavior-driven development (BDD) Definition of ready (DoR) Design sprint (User experience (UX)) Detailed requirements specification High-level requirements specification Just-in-time (JIT) model storming Look-ahead modeling/backlog refinement Split (A/B) testing

    Figure 1. The Address Changing Stakeholder Needs process goal diagram.

    Click the diagram to open the interactive DA Browser, where you can learn more about the decision points and options of this goal.

    Why This is Important

    There are several reasons why this goal is important:

    1. Teams do more than implement new requirements. Yes, stakeholders need our team to implement the new requirements that they come up with. But they also need us to fix the defects that are found when using the solution, they need us to support other teams working in parallel to our own, they need us to learn and grow as professionals, and they need us to improve the quality of our implementations. The implication is that their needs will generate a range of work item types, or “classes of service.” This includes, but is not limited to, new requirements, changed/evolved requirements, defect fixes, growing team members through training or education events, paying down technical debt, and running experiments.
    2. Stakeholder needs will change. There are a variety of reasons why stakeholder needs change, including gaining insight during a demo, your competitors releasing a competing offering that your stakeholders need to react to, technology changes, legislation changes, and many more good reasons. Requirements evolution is not scope creep, but rather our understanding of the true needs grows and thus enables us to deliver a better end product. Disciplined Agilists embrace the fact that change is natural.
    3. We want to explore requirements details at the last most responsible moment. By doing so, we can focus on what our stakeholders actually need. The longer we wait to gather the details, the more we’ll know about the domain and therefore will be able to ask more intelligent questions. Likewise, our stakeholders will have seen the solution developed over time so will be able to give us better answers. The bottom line is that by waiting we can focus and have better conversations.
    4. The changes need to be managed. Part of embracing change is managing those changes so that we react appropriately to them. Change is good and natural, but uncontrolled change is not. We need to exhibit some degree of discipline regarding change so that we can meet the delivery expectations of our stakeholders.

    Important Questions to Consider

    • How will we work with stakeholders?
    • How will our team elicit feedback from stakeholders?
    • How will we explore the problem space? 

    Key Points

    • A team will receive feedback on a regular basis that reflects the changing understanding of what stakeholders believe they need.
    • On many teams, product owners are responsible for eliciting and prioritizing changing stakeholder needs, but there are other (and sometimes better) options to help accomplish these things.

    January 2023