Why Scrum is SMART

The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. f Product Backlog items have the attributes of a description, order, estimate and value.

To create and maintain the backlog, we capture every work item in the backlog, we clarify each Product Backlog Item with a definition of success and story point estimate, we organize (or rank) PBIs by business value, plan the next iteration, and —“Engage, ensign!”

For more about GTD, see Getting Things Done in Wikipedia.

SMART objectives are Specific, Measurable, Attainable, Relevant, and Timeboxed — which is literally the definition of a well-written Scrum story (or Product Backlog item).

We specify user stories and a definition of success for each story, to be sure it’s attainable and relevant, and measure the effort for each story, as well as our overall velocity for a sprint.  We timebox our work into a set increment, and only accept the amount of work that can fit into that box.

Churning can be a real problem for developers.  It’s easy to go down a rabbit hole, and keep thinking one more code-build-test cycle will do it.  Thirty builds later, you’re still churning.

I’ve been known to set a two-hour timer on my phone, to force myself to take a break from whatever I’m doing, so I don’t spend an entire day hitting compile like perpetual-motion drinking bird.

The classic Pomodoro Technique uses an even smaller increment of 30 minutes, but the principle is the same.  Don’t get lost in the weeds, you need to come up for air regularly.

For more, see Pomodoro Technique in Wikipedia.

To squelch the “tyranny of the urgent”, Scrum teams take a step back and conclude each sprint with review and retrospective ceremonies.

• Sprint review captures feedback from the product owner and any other stakeholders that attend the review.
• Sprint retrospective captures feedback from the team itself on ways they can improve their internal process.
  • It’s been well-said that if you adopt one Scrum ceremony, let it be the retrospective … and the rest will follow.

Feedback is essential to every time management or project management systems.  Otherwise, as it says in the Seven Habits, it’s way too easy to cut down the wrong forest.

For more about why Agile uses tight feedback loops, see the ever-popular Project Management Tree Swing Cartoon. (Really, you should!)

The inimitable Robert C. Martin presents an alternative view of Scrum and Agile in his entertaining and thought-provoking presentation, “The Land that Scrum Forgot”.  If you haven’t seen it, it’s well worth viewing and sharing.

• The Land that Scrum Forgot (YouTube)

Gotta love Uncle Bob!

Like most folks, we use two-week iterations (synced with payday!), and I’m continually impressed by the effort everyone puts into our blameless retrospectives.  Beforehand, we setup a Confluence page with Start/Stop/Continue sections that fills up quickly with suggestions and counter-suggestions, which we discuss at the live meeting.

Following Spotify’s lead, we also have several “guilds” where people on different squads can collaborate on shared concerns.  The newest is the Developer Experience (DX) Guild, where we coordinate devops tech between feature, upgrade, and implementation squads.  Other guilds include Data Management, Training, Technical Writing, Innovation, Software Standards — and a Social Guild for enjoying the ride outside the office.

My personal tip would be to avoid “Scrum but” like the plague.  First, use the framework as designed, and then go for “Scrum plus”.  A good practice is to set up a copy of the Scrum Guide on your company wiki, and annotate it with how you apply and extend the framework.

And, if you use Scrum, do fight hard for the infrastructure stories.  As developers, it’s on us to be sure product owners understand — before the jalopy runs dry — when we’ve been too busy driving to get gas.

Great infrastructure is the best way to enjoy the ride!