Just Say No...

Updated: Jan 13

by Guest Blogger - Roger Brown

Scrum is, by design, a “pull system” rather than a “push system”. The Scrum Team determines how much work they will pull in to each Sprint. The Product Owner determines what items are ready to be pulled in according to priority.

There are legacy forces that work against pull systems, trying to push work into both Product and Sprint Backlogs. These include stakeholder requests, maintenance fixes and client feature changes. Scrum is designed to absorb feature requests and changes by buffering them into the Product Backlog. Maintenance work is buffered by defining a set percentage of Sprint time for fixes and paying down technical debt. Ideally, a new product is built using Agile engineering practices that make maintenance virtually unnecessary.

There are times, however, when the legacy forces overpower the Scrum machine. This is especially true in organizations new to Agile principles and practices or lacking in proper training so that Agile Development is not implemented as designed. Another common case is when Agile Development is attempted for a business client under a traditional fixed-cost, fixed-scope, fixed time contract. Such contracts are typically underestimated and then stressed further with scope changes.

When a Scrum Team is pushed, these desired attributes are compromised or lost: quality of product, quality of life for the team, predictability from invalid velocity data, resilience to other surprises. To preserve these attributes and maintain a healthy, productive team – one of the most valuable assets a company can have – there are times when it is necessary to “just say no”. Since saying “no” runs counter to traditional software development protocol, here are some tips on how to say no more judiciously.

Product Backlog Protection

When a Product Owner is asked to add to the Product Backlog, there are other ways to achieve the effect of “just say no” without using those words.

  1. Say “Not Yet”, because there are other things that need to be done first according to priority order or dependency build-out. Some of the common secondary artifacts can help here. The Product Vision can help if the request is not in line with the vision. The Product Roadmap can help show where in the desired timeline the request might fit in better. The current Product backlog itself can help, along with a Release Burnup that shows the current release goals and progress towards them.

  2. The prioritization method in use for the Product Backlog can help by having a category for “Wont” with a less final name such as “For Consideration”.

  3. When the requestor is an external client asking for a fixed-everything contract, try to sh