The Dog Food Diet: Sprint 6

messywiresSprint Goal: Cleanup installed hardware and implement one internal-feedback controlled function.

We’ve explicitly excluded physical aesthetics from this first release but there are limits to everything and the mess of wires in production threaten to make trouble down the road.  Add to that the fact that we need to take production apart to enable some of the control-function stories (wires that weren’t brought out to an accessible terminal) and it makes sense for this to be a goal.   Feedback controlled function is the embedded system making an intelligent, sensor-based, not schedule-based, local decision to “do something”.

Sprint Planning:  Our velocity is 54 and we take 54, including an interrupt buffer which we eyeball at 10 points.

Everyone’s anxious that the product backlog is thinning out and starting to be dominated by business value research stories, bigger, more difficult technical stories and stories that apply more strongly to a commercial version of the product than to an in-house version.  A decision point is looming for our PO structure.

Sprint Review: We showed the radically reorganized installed hardware and a control function directed by internal sensor feedback.   The sprint goal was met, and with room to spare.

Screen Shot 2017-12-20 at 6.41.10 PM

Retrospective:  Lots to talk about at this retro.  Looking at the chart, we flat-lined for the first three days, got on the curve then flat-lined again.  We’re repeating a pattern of floating “above the curve” for most of the sprint and bringing it in, if we do, at the end of the second week.  This could mean we’re taking in stories that are too big but looking at the second half of the burndown chart report we see that the stories we burned were all ones, twos and threes so we’re good there.

This floating above the curve phenomenon is a builtin tension to doing almost anything, by almost any methodology.  Jeff Sutherland always compares burning down work to landing an airplane which is a great visual analogy.   The biggest problem with floating above the curve as a way of life is that it has a completely ill effect on both the Scrum Master and Product Owner.  Your SM and PO can have confidence that you’ll land the plane, but it will be based on faith, and history, not on the current state of the chart.  There may be a happiness metric benefit to, every now and then, taking a quick win at the start of the sprint.

Despite our velocity, we also had three dangling stories that fell into two camps.  One was a story that was complete except for deployment to production.  Remember, like any ongoing business we’re limited in our access to production and the size of the window we can bring it down.

The other was a pair of stories having to do with controlling a motor.  The team fears it.  It’s messy and risky so no one wants to touch it.  It was probably a mistake to put them at the end of the sprint backlog where they’d be easier to punt.  We’ll swarm at least one of them at the beginning of Sprint 7.

Jira note: We took in two stories about the same physical part – a three pointer to jury-rig it to get another week out of it, and a five pointer to replace it entirely.  We ended up doing the five pointer on day eight without needing to do the jury-rig so we removed the three pointer from the sprint.  In the burndown chart that descoping is represented just like completed work, but Jira is smart enough not to count it toward our velocity.

How did our kaizen from Sprint 5 work out, part 1?  TDD – TDD was epic.  The team loves it so much we started looking at BDD.  Note that like most everything that seems radical and new, BDD is actually a decade old now.

When we took this kaizen, we estimated it at 5 points.  Then I realized that it was stupid to size this kaizen.  That’s what you see on day 5 where five points disappear from the scope of the sprint.  My thinking here went as follows.  TDD requires effort, but that effort for each story is part of the story itself, not a separately sized thing.  And theoretically it should be speeding us up, so if we count velocity for doing TDD and get a velocity bump on the individual stories, we’ll be double-counting one kaizen which we’ll have to “give back” next sprint when it’s not the kaizen anymore.

So put the kaizen on the backlog, but don’t size it because it doesn’t directly create business value.

How did our kaizen from Sprint 5 work out, part 2?  The interrupt buffer came in handy almost immediately.  On the fifth day of the sprint we had a production emergency, three point story.  So we added a three point story to the sprint backlog.  But we want those three points to “come out of the interrupt buffer”.  So we reduced the point estimate on the interrupt buffer to seven.  That’s the spike that shows up on day 5.  Adding three points of scope for the new stories, subtracting three points of scope from the interrupt buffer.  And when we burned down those three points on the same day, we end up, as we expect, on the same slope as if we’d just burned a three-pointer from the sprint backlog.


About JR
Software guy, startup guy, non-fiction glutton, south shore inhabitant

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: