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.
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.
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”.
When the requestor is an external client asking for a fixed-everything contract, try to shift to one of the forms of Agile contract. Sell them ‘adaptability’ instead of busy workers. Ask them to be the Product Owner, or at least provide ongoing input to prioritization in the Product Backlog”. The client usually changes their mind more than once. The Team should not have to pay the price. The ability to change their mind is a valuable feature of Agile, not a bug.
Avoid quick agreement to unplanned feature requests. Give them time to “settle”. There is a common corporate dynamic that may sound familiar. A request comes in from a Very Important Person. You agree to it quickly, work hard to deliver quickly and then find out that it really wasn’t that important after all. “Oh, Joe did that for me already, but thanks.” If you take a new request under consideration for the future, it may lose importance before you get to it.
Sprint Backlog Protection
Scrum says that new work is not to be inserted into the Sprint. The Scrum Team creates the Sprint Backlog in their Sprint Planning meeting and from that point on only the Team can change it by pulling in more items from the Product Backlog if they get ahead of the plan or putting items back if the plan is not likely to be achieved.
But it is sadly common for Teams to be asked to do something that is not planned for the Sprint. Here are to ways to say “no”:
Ask “Can it really not wait three weeks?” That is the average time for something new to be accomplished if the Sprint length is 2 weeks. The Team is, in a probability sense, in the middle of this Sprint. If the item is important enough to enter the next Sprint then the wait time is 1.5 Sprints. How many requests are so critical that they can’t wait that long? (End user-impacting emergencies like service outages are an exception, of course.)
“Which two items shall we remove from the Sprint?” A reasonable rule of thumb is that a new, unplanned item inserted into a Sprint will cost two planned items. Clearly one must be removed to make room for the new item. Another item’s worth of work will be created by context switching, elaborating the new item and backing out any work done that will not be completed. If the requesting Stakeholder is invested in the other work of the Sprint, they may well reconsider the new request, possibly accepting the Sprint and a Half Option described above.
The topic of absorbing maintenance work in the Sprint is a big one so we will discuss that in another article.
These tips for constructive reframing of “just say no” may be helpful in protecting the Team while educating your Stakeholders to the underlying “pull” aspect of Agile Development. A smooth, predictable flow benefits everyone and response to change can still be orders of magnitude quicker than anything we had in the pre-Agile past. Everyone wins.