A familiar scenario played out today on one of our Scrum projects. The customer had been thinking about one of the administration screens and how it could be enhanced. The requirements for it had already been baselined for the Sprint, but they were really interested in the new functionality.
On this particular project the last few times the developer has decided well, OK that isn’t too big a change, I’m sure we can get it done in the Sprint anyway. I’ve had several conversations asking questions about whether that made the most sense and shouldn’t we put it on the backlog, but they always felt they could get it done, and it wasn’t that big of a change. Much of this is probably attributable to trying to serve the customer, the product owner in this case.
Over the last two Sprints that scenario played out in predictable pattern. The developer simply wasn’t able to get all the changes in within the Sprint, or they delivered a day or two before the end of the Sprint to QA and so it wasn’t tested within the Sprint. Looks like the third time the lesson has sunk in.
I debated being hard-nosed and forcing the issue to be put on the backlog, but it’s really up to the team and the Scrum Master on the project didn’t balk, so I think it ended up as a much more valuable lesson learned. They might not have understood had I simply forced the issue onto the backlog. As Scrum Master I might have thought differently, but as a manager I think it’s better to let people make their own choices.
I think from now on we’ll see a lot more pushed onto the backlog and not forced into the current Sprint.