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.

Steve Gentile recently had a thinking out loud moment by posting the Agile Manifest as a reminder to himself of what he values.  It’s really important to constantly put these types of reminders in front of ourselves as we work in environments that don’t necessarily breed best practices.  The contractual obligations of the business world definitely don’t lend to “welcoming change.”  Often our focus on “getting paid” blinds us to the goal of “continuous delivery of valuable software.”

It is a test of our dedication that we continually reassess our values and attempt to embed them more deeply in our daily activities..

Scrum introduces the concept of Story Points which most teams immediately misunderstand or discard.  The most elegant wrong explanation I’ve heard for not using story points was:

“we never liked story points, because then we had to communicate and teach our customers a whole new currency.” 

Fortunately, this isn’t true.  Unforunately, the reason many find story points hard to implement is because we seem to have a hard time differentiating Size from Duration.  Add Effort to the equation and you have your own little math game.  In fact, you get the mathematics of Project Management.  Blasphemy!

Here is the anecdote I’ve been using for a while now and it seems to work at least in explaining the difference.  I have two puzzles, one with 25 pieces and one with 100 pieces.  Each puzzle has pieces roughly the same size and complexity in imagery.  That being said, the 100 piece puzzle is 4 times as difficult as the 25 piece puzzle.  If I put 1 hours worth of effort into each puzzle per week, the duration until completion of the large 100 piece puzzle should be approximately 4 times longer.  Ho long (duration) it takes me to complete the puzzle is a factor of the effort and size.  Size doesn’t change, effort can.

Story Points are a relative unit of measure for size.  If my only two tasks are the two puzzles, the smaller could well be 1 Story Point, while the larger would be 4 Story Points.  If we find that a third puzzle of 12 pieces is added to the task list, it could be 1 Story Point, the 25 piece puzzle becomes a 2 and the final 100 piece puzzle would become an 8 Story Point Task.