We've got a scope management problem

We've got a scope management problem

I think it's time to admit it - as a team, we're horrible at scope management. Now that it's been said, we can dig in a bit as to why exactly that is.

Sprints and scope

In the grand scheme of things, we're still an immature team when it comes to operating in an agile manner. We're trying to mature as quickly as we reasonably can, but until we've matured, there are some tenets that are being restated time and time again; namely..

  • Our sprint commitments are sacred and need to be respected
  • Our commitments (and our successes and failures) apply to the team, not individuals

Those rules don't need to stop us from constantly conducting intake and grooming new features and stories based on the needs of our customers. They also don't stop us from including work in our sprint to resolve defects or re-prioritized items as they arise.

These rules do allow us to converse with our customers with confidence; we can discuss current commitments and work in progress. We can show the customers the great progress we're making and give them (distant) insight into all the things we're doing for them.

And, when the inevitable re-prioritization happens, or when the defects from testing new functionality start rolling in, we have the ability to push back. We can use that same confidence to show the customer that our plates are full; we get to have a productive discussion around what trade-offs need to be made to change focus.

The more conversations we have like that, the easier it gets. The more conversations we have like that, the more the customer understands about how we work and how disruptive churn can be to the work we have and the deliveries we've promised. In our case, everything above falls apart at the very start of our intake and prioritization process.

Intake and unplanned work

Our intake and prioritization process is a work in progress. We're finding ways to better optimize it, we're refactoring it whenever (and wherever) it makes sense. Everyone on our development team has the ability to help us make this process ours. But for all of our optimization, this intake process fails in two different scenarios:

  1. We're omitted from or passively involved in our intake process
  2. We're actively ignoring our current scope

These two items are the undoing of all of the hard work and growth we attempt.

When we're involved in our demand intake process (it is our process, so of course we should be involved), we have a penchant for only being passively involved. Our passive involvement definitely does us a disservice. We tend to miss discussions around delivery timing and criticality; as a result, we constantly have to shift priorities and halt work already in progress.

This opens the door for angry conversations around what exactly we're working on and whether or not it's actually what the customer wants and needs.

We also have a penchant for chasing issues in all of our environments, taking on completely unrelated work at the expense of almost everything we've promised for delivery. Something looks like it may have rendered slightly off-center on our landing page? Better dive right in and figure out what's causing that, never mind that it would take three days of research to figure out it's a quirk only present in IE9.

To complete the picture here, in addition to the flaws above, we never say no. Regardless of the demand, size of the work in question, or how irrational or not the delivery deadline is, we never push back. Or, in the event we push back, we cave in under the slightest bit of added pressure. On average, we tend to expand our sprint scope by between 25 and 65% per sprint. That's right...per sprint.

That percentage alone highlights the lack of scope management we have, and it only represents the total percent change of points in the sprint, not the quantity of stories or commitments. There's no discussion about moving work out of the sprint to accomodate new, higher priority requests. We're no longer in control of our own destiny.

How we fix it

None of the issues above are completely unsolvable - in fact, they're possibly the most solvable problems we have. The only thing that needs to be done to solve them are changes to how we, as individual team members, take responsibility for our actions.

We need to be actively engaged in our intake pipelines. There's no room to disconnect, no room for out-of-band conversations, and no room for promises that aren't accepted by all of the stakeholders.

We need to drive ourselves to complete our commitments and follow our work prioritization. We as a team have agreed on a prioritization of...

  1. SEV1 production events
  2. Sprint commitments
  3. Everything else

We need to hold ourselves and each other accountable to those priorities and accept no justification or explanation as to why someone isn't honoring that priority.

And, most of all, we need to learn how to say not yet. We've let our customers run rampant with constant changes to work prioritization and demands. Just as we need to hold ourselves accountable for the commitments we make, we need to hold our customers accountable when they try to shift our commitments after we've started working on them and make sure they understand completely what they're asking for.

It's OK to say "no", and if we can't hold ourselves accountable, then we're never going to stop failing on our commitments as a team.

Subscribe to Adam Margherio

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
jamie@example.com
Subscribe