We are currently mid-sprint and the client just dropped a massive "must-have" feature that wasn't in the initial backlog. I’m worried about our project management professional standards if we keep saying yes. How do you guys manage these sudden changes without burning out the team or missing the hard deadline for the increment?
3 answers
When you’re facing unexpected shifts mid-sprint, the first step is to lean into the core principles of transparency and negotiation. As a lead, you must facilitate a conversation between the Product Owner and the development team immediately. If this new feature is truly a "must-have," then something of equal effort must be moved out of the current sprint and back into the product backlog. You cannot simply add to a fixed-capacity sprint without compromising quality or team health. Protect your sprint goal at all costs, or you'll find that your velocity becomes unpredictable in future cycles.
I’ve seen this happen way too often in my department. Are you guys currently using a formal change control process, or is the Product Owner just bypassing the usual channels? It sounds like there might be a gap in how the initial requirements were gathered.
You should definitely check your team's current velocity. If you are consistently over-committing because of these "surprises," your burndown chart will reflect the chaos.
Karen is spot on. Using data from the burndown chart is the best way to show stakeholders the physical impossibility of adding more work without moving the deadline.
Hey Michael, to answer your question, we do have a process, but the stakeholder is a high-level executive who tends to push things through. It’s definitely a culture issue more than a process issue, but I’m trying to use the framework to push back. We’re going to try the "one-in, one-out" rule this afternoon to see if they realize the impact on the timeline.