Engaged, passionate team members are the base of any great Scrum team or any Agile team for that matter. Without passion and without engagement, quality is a burden and continual team introspection demands dragging lumber up hill. There is a downside to passion at times and it’s the dream of every Product Owner.
We’ve all been in that euphoric place in which evenings slip away as we code up the next great feature or experience, our children peering into the windows of our office as we work 14 hour days to play. We’re coders, we love this stuff. At our Sprint Review, we bask in the glory of our Stakeholders’ and Product Owner’s praises ensuring them it was nothing. During our Sprint Review, though, we reveal that we’ve just increased our velocity from 50 story points to 75 story points. Incredible! Stakeholders’ and the Product Owner are now confident we will have at least 60 story points completed in the next sprint, probably 75 though if we aren’t interrupted (something we’ve always been asking for).
Unfortunately, in the next sprint the Product Owner presents the Product Backlog item for Miles the accountant to add in an export button with a spinning fire “Please Wait” icon so he can report last month’s TPS metrics. Bummed out, we work at our more natural pace (or drag our feet while mumbling expletives about “Real Business Value”).
Sound familiar?
I’m all for passion and cool features, I get excited and pull all-nighters myself. Unfortunately, as you just saw, they they tend to unnaturally inflate our velocity, setting us up for failure in following sprints. More over, as the saying goes there is no such thing as a free lunch or bonus features. Every line of code you write must be maintained going forward. That includes fixing bugs and unforeseen technical debt accrued as a result of the new feature. (Opinion: Unlike monetary debt, technical debt is rarely known or acknowledged when created).
The principals and practices of Scrum help us to create a sustainable pace and there are practices to enable passionate developers while also maintaining a sustainable pace. Often times these exciting features are accepted into a sprint as Stretch Goals. They don’t “have” to be completed, but it would be cool if they were. This is a slippery slope and, arguably, an anti-pattern. If you must scratch that itch, even in your “own time” (that doesn’t exist, by the way), leave it in your own branch and keep it there until the PBI comes up. You could well have lowered the risk of the PBI or increased the cost/benefit analysis in some other way, but until it is selected by the Product Owner it is not an important enough feature to accrue the side-affects created.