Demo the product

The demo is conducted with the working team and stakeholders. The session lasts from thirty minutes to an hour and a half, depending on the amount of functionality that is being walked through. The objectives of the session are as follows:

• Review project health such as financials, schedule, and backlog.
• Demonstrate working software to collect stakeholders’ feedback.
• Present the upcoming work planned for the next sprint.

The product manager schedules the demo. Shipped functionality is presented by team members orchestrating the work. Ideally, the individual running the demo rotates through the team so that all contributors have an opportunity to present. This improves ownership and also helps to keep everyone engaged throughout the session.

Rehearse the demo before meeting with the client. Each member of the team must be familiar with and effective at describing the user story and the acceptance criteria, as well as be able to demonstrate the working software.

Enforcing stakeholder attendance

Stakeholder attendance is mandatory. If they skip multiple demo sessions, the project should fall into “red” status and escalate to senior management both at Devbridge and the client’s side.

A few other objectives during the demo:

• Collect feedback from stakeholders and document it in Confluence.
• Record, store, and distribute video sessions to team members and the group of stakeholders.
• Provide a link in the sprint update via PowerUp. This documentation and distribution allow absent team members and stakeholders to stay up to date.

Handling changes

As part of the introduction to the session, the product manager instructs the room to write down feedback, so everyone is able to share their thoughts once demo is complete. This helps manage timing and prevent interruptions during the presentation.

Diligently capture this feedback—even if the team does not immediately agree on the priority. The point is to hear all participants, thus fostering an inclusive atmosphere. Avoid discussions and negotiations until after the demo.

Identify and capture changes or defects as stories. Then add them to the backlog for refinement and prioritization.

Presenting stories for the next sprint

The client was hopefully involved in the refinement activities that have happened all throughout the current sprint and is aware of the backlog contents. Discussions around priority and Definition of Ready should have been taking place before the demo so that the tail end of the demo could be used to communicate with stakeholders the planned work for the following sprint. The demo should not be used as a session to debate priorities but rather to inform the full team on priorities selected for the sprint.

Providing release plan updates

After collecting feedback, the product manager reviews the financials and schedule. Use the project health report as a starting point for this conversation. In preparing the update documentation, factor in and include the following information (if relevant to the project):

• Project status: Explain why the project is in its current status (green, amber, or red) and what is necessary to move it to green if it isn’t there already.
• Risks and assumptions: Go over all monitored risks such as third-party dependencies. Verify that assumptions have not changed.
• Blockers: Note any integrations, environments, access, or other issues that are actively preventing the team from working on features or that pose a significant risk to future sprints.
• Change requests: Review stories and the financial impact of any change requests that originated as part of the sprint.
• Schedule and funding: Share burn-down and burn-up charts and discuss to-date patterns in velocity, anticipated finish date, and anticipated investment needs, in addition to any needed changes.

The need for change requests is often debated, but I recommend erring on the conservative side. Mature product teams that use theme-based funding with clear product outcomes may not need CRs—the trust has been established with the client, results demonstrated, and the ambiguous nature of the product may introduce an expensive overhead if each change is managed through a CR. CRs become critical, however, in the following scenarios:

• Constrictive funding methodologies are used. For example, a small team is funded using a not-to-exceed or, worst case, a fixed-bid contract. Any change in assumptions, risks, or scope should be captured with a CR as there is little room for flexibility from a budget perspective.
• Trust not established with client. Clients that do not understand real value behind Agile will be uncomfortable with the lack of perceived control. Any change in scope, funding, schedule, or deviation from estimates needs to be tracked, documented as CRs, and countersigned by the client. Once the trust is established and we have delivered results as proof, flexibility can be introduced.
• Feature parity work. Request for feature parity is often a misrepresentation of the reality. Product debt starts seeping into the technical backlog the moment business realizes that a piece of software is being rewritten. Often unavoidable and thus important to capture through CRs.

Addressing budget after the demo

While it is important to facilitate collection of feedback and inbound requests, the prioritization and funding of changes is a topic for discussion with the primary stakeholder or sponsor—outside the demo session. These conversations are better held one-on-one in case the sponsor needs to override priorities—it’s their prerogative to get the product shipped. Document the sponsor’s direction and bring this information to the next refinement session.