A common fear about agile is that it makes the job of managing scope difficult for your project. This can be true, however, a golden rule of agile software development is that the scope of each iteration or sprint must be completely locked-down once it begins. This means no new requirements, no swapping of requirements and also no shifting of the end date.
Allowing a new requirement into the current sprint may increase the satisfaction of the business in the short term, however, there are many serious longer term implications. The most serious concern is that the business or product owner will not take the process of preparing requirements prior to the sprint seriously and will always feel that things can be “snuck in” if they haven’t done a thorough job of preparing and prioritising requirements.
Another concern is that the team will lose focus and their sense of commitment about what they agreed to deliver. This is a quick way for the “self managing” team to lose their sense of responsibility.
This is always tricky and requires a high degree of diplomacy, however, the best way to deal with this situation is to push back on the customer and let them know that it will be the first requirement to be included in the next sprint. If this is still not appropriate, simply stop the current sprint and plan out a new one with the new requirement included.
Posted by Paul Jackson on March 24, 2010 at 3:46 pm
Hi Adam,
There’s some really useful guidance here, particularly when a new Scrum Master is implementing Scrum within an organisation.
I faced exactly this problem only last week having joined a new organisation and kicked off the first Sprint ever; the [new] Product Owner tried to add in a “small fix” mid-Sprint by emailing one of the developers. Luckily the developer forwarded this on to me. I had a chat with the PO, explained the Sprint rules and suggested that we discuss this Story at the next Sprint Planning Meeting; if it’s still a high priority then we’ll add it in to the next Sprint. The PO was happy with this approach and the developer was grateful that the decision was taken out of his hands.
One point I differ on, though, is swapping requirements. In the early days of Scrum implementation, it can take a while for the PO to understand which stories provide the best business value, so sometimes mid-Sprint they realise this and ask to swap a requirement. I explain that we lock-down the requirements in a Sprint but then allow them to do a swap once and only once and then only if:
There’s time in the Sprint to complete the Story
The Story to be swapped is the same estimate size as the one to be removed.
They understand that they’ve now played their Joker Card, so no further swapping will be allowed – ever.
This educates the PO about the Scrum process but also allows them to recover from their earlier prioritisation. It encourages a “team” ethos rather than them and us, adds in some pragmatism, but allows me to retain control of Sprint scope.
Hope all is well with BGP and business is brisk!
Cheers,
Paul
Posted by Adam Feldman on March 25, 2010 at 12:54 am
Hi Paul – Thanks for your comment. Managing the scope of each sprint is critical, it’s the only way that we can be so responsive to change without things getting out of hand.
I 100% agree with you that requirements should not be swapped in and out. This should only be done with requirements that are in the backlog. I like your “joker card” idea too…..
Adam