The Dog Food Diet: Sprint 7


This project, as it stands today, is clear proof of the axiom that beauty is in the eye of the beholder.  As a Project Management Professional looking at this project I’d be horrified at the size of the remaining backlog.  As a Business Analyst, I’d be appalled that critical features have fallen to the bottom of the backlog.  As a Product Designer, I’d be miffed that we’ve done the absolute minimum design we could get away with.  And as a Scrum Trainer and Coach I am embarrassed at some of the #scrumfail we’ve committed.

As a Scrum Product Owner, though, I’d be … content.  To understand why, we have to look at one of the recurring impediments in this project – one that really blew up in Sprint 7.

We want to be ‘hardcore’ Scrum.  The stricter you are about working the methodology, the faster you deliver value.  That’s the theory, and amidst the various #scrumfails we’ve clung grimly to it.  So we’ve kept our Definition of Done strict, which includes deployment to production.  As a result, we left 15 points undone in Sprint 7 not because we couldn’t do it, but because we couldn’t get in to production to deploy it.

Our access to production has always been limited but in Sprint 7 it was nearly completely shut off.  Why?  Because the product worked so well that we’d come to rely on it.  The value of the new features didn’t outweigh the cost of shutting down production for the time it took to deploy them.

In six sprints we’d gone from not having it at all, to completely relying on it.

Our burndown (see below) screams #scrumfail, but we’re completely reliant on the thing that got built.  That’s success.  We’ve proved the 80/20 rule of product management – 80% of the value is in 20% of the features.  What’s left in the backlog is largely the 80% of the features that provide only 20% of the value.

Screen Shot 2017-12-20 at 6.45.48 PM.png

As a team member building the product, I really want to build those features.  As a Product Manager, I really want to be able to sell those features.   But as a business, we really didn’t need those features.  Who could have known?

The business can choose to do, or not do, what remains on the backlog.  The relentless prioritization in Scrum has forced us to build first, only what is provably most valuable.  Remember in our last post – Product Management Interlude – I looked ahead and guessed we’d be done somewhere around Sprint 10?  Even then, it hadn’t yet struck me how close we were to an MVP for this product.  Yet here we are, at the end of Sprint 7 with what is needed, and nothing more.  That, to me, is beautiful.

Luke, I AM Your Father

All that remains to be done on this project, the real must-haves, is a small amount of cleanup/future-proofing, some market analysis, and a case presentation to management of the commercialization question.

So this constitutes a bit of a “surprise ending” to a series that was supposed to be about spinning up a kick-ass Scrum team and doing a project.  Our Scrum board and burndowns are still full of #scrumfail, but when the product’s done, well … it’s done.  So as the team backlog has already started filling up with ‘the next thing’, now seems like a good time to wind up this series, at least as far as following the action sprint to sprint goes.

Post Mortem

I intended this series to show Scrum in action, warts and all, on a real project.  I didn’t know how it would turn out.  There are a few things that I find notable about it.

  • My expectation was that we’d take a couple of sprints to get a baseline velocity then progress upward from there.  But it didn’t work out that way.  In the end, our velocity was all over the place.
  • I expected that, since we know our Scrum, we’d dive right in and put on a Scrum clinic.  It turned out that it took us several sprints to start doing it right.  The pull of the dark side, over-commitment particularly, is strong.
  • I never dreamed that we’d end up declaring victory this early with so many of the original stories drowning at the bottom of the backlog.  Knowing that the methodology drives that phenomenon is one thing, but seeing it in action is quite another.
  • I spent a lot of time pointing out where 1-week sprints instead of 2-week probably would have helped us fix our #scrumfail faster.  That said, my opinion of 1-week sprints remains unchanged.  IMHO, 1-week sprints are just another way for project managers to steal your weekend.

The Dog Food Diet: A Product Ownership Interlude


As Dilbert once said (sort of) “Welcome to product management.  Two drink minimum.”  At this point, 6 sprints into the project our release burndown looks something like this:

Screen Shot 2017-12-20 at 6.53.15 PM

Aaaaaaannnnnnyyyyyyyhooo …. 

This release is going to happen, probably sometime around Sprint 10.  There is no question that the product works and the functional release goals will be substantially met.  There are stories that have appeared out of nowhere and gone to the top of the backlog, stories that seemed critical that have fallen to the bottom of the backlog and stories that have failed in execution and had to be reworked from scratch.

Given that this is an internal release there’s little angst that goes into “calling it done”.  The more interesting questions revolve around what comes next.  After this release we’ll have something with a positive ROI when sold to one customer, us.  What about customers who aren’t “us”?

Up to this point we’ve put a small handful of PO stories on the backlog.  Generating lean canvas for the product, maintaining an up-to-date bill of materials to give us an upper-limit unit cost, and some better-than-internal documentation.  Now our PO needs to build a decision about whether or not to sell the product to people who aren’t “us”.

We’ve reached a commercialize-or-not decision for the product.  The team, including the PO, desperately wants to commercialize.  You want them to want this.  “Purpose” is a key part of motivation (Autonomy, Mastery, Purpose) and if your team doesn’t feel they are serving a big, worthwhile purpose then they won’t perform well.  But this means that if the team and PO just sit down and talk about whether or not to commercialize all you’ll hear is various flavors of “Hell yeah!”.  We need metrics.

Because of the company’s unique (alright not-so-unique) position, “time to break-even” and “maximum exposure before break-even” put hard limits on the investment we can make in the product.  A version of the product that takes too long to break even, or takes too much investment to launch at all would require the company to bring in a round of investment, which pushes the decision up a level from the PO/Management Team level where it lives now.  Again, typical constraints.

Getting those metrics done well, and being hard-headed about them is top priority.  What do we need to get those metrics?  For this particular product:

  • Cost of labor to build this.  This should fall out from a well-constructed product backlog and the velocity metrics we’ve already produced.
  • Legal and regulatory.  There are expensive regulations that need to be met to commercialize this, we know what they are, we just need hard numbers and timelines about how to meet them.
  • Cost of go-to-market.  Given a product that meets regulatory and does things people will pay for, what does it cost us to get them to buy enough of it that we reach break-even without breaking our total investment ceiling?

Second priority is the potential return on this investment.  We split this into two questions that will look familiar to fans of Lean Customer Development:

  • Does anyone besides us have the problem this product solves?
  • How many people have this problem and what will they pay to solve it?

Scrum Implications of Commercialization Decision

2drink.pngWhat does all this mean for the team?  In large companies, except for the BOM and people-cost, all this “business stuff” would disappear into a black hole of decision-making populated by business trolls doing exclusively business stuff.  But we’re a small company and we need to do all this with pretty much the same team that’s actually building the product.

We’ll use a typical structure that enables swarming.  Our PO will structure the Lean Customer Development stories, and the team/PO will figure out how to get them done and run them off the same Sprint Backlog that we build the product from.

On top of all that, the team realizes that given the amount of work and sheer calendar time that needs to go into this decision, we’re very late getting started.  Customer development interviews, in particular, eat calendar time.  We’ve already started Sprint 6, with almost exclusively product development stories and won’t want to wait two weeks to start on commercialization stories.  Fortunately, our kaizen from Sprint 5 was to implement the interrupt buffer pattern and we now have 10 points of interrupt we can draw from without angst.

So What Do We Do First?

There’s a bunch of stuff we need to do to build this commercialization decision.  That stuff becomes stories on our product backlog.  Our team is doing backlog refinement weekly, so our PO needs to write those stories, get them sized and prioritized, recognizing that he has only 10 points of interrupt for this sprint where he can jam in unplanned work.

Notes on sprint length (are you bored with sprint length yet?). This once again argues for one week sprints over two weeks.   Realizing that it will take at least a couple of days to create new PO stories, we could easily put off starting on them until next week in a one week sprint system.  In a two-week sprint system we’re forced to use interrupt buffer to accommodate the urgency of these PO stories.






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.


The Dog Food Diet: Sprint 5

superman-1275374_1920Sprint Goal: At least one control-function installed and working within physical element and more sensors reporting actual values.  Until now the embedded system has been reporting values to the web, but not responding to commands from the web.  Now we want to largely complete the reporting function and implement one instance of the control function.

Sprint Planning: Backlog was in good shape, our velocity was 40, we took 40.

Sprint Review: We showed one control-function working within the embedded unit.  The one we chose to show was run from a schedule within the device, rather than controlled from the web because that was highest value to the PO.  The team using the system didn’t need manual control (which was also harder) but simple scheduled control.

Retrospective: Finally it all seemed to click.  We under-committed our actual velocity and finished early, way early, then piled on the wins.

Note that we burned down to our last committed story on the 11th day of our 14 day sprint, then started taking stories off the backlog without taking the last one to done.  The last story was blocked temporarily.  The sprint goal was already crushed, and we knew we’d get that last one in so we went to the backlog and ended up completing 6 more stories in addition to the last one from the commit.

How did our kaizen from Sprint 4 work out?

We more than doubled our velocity from Sprint 4.  Our official kaizen was to only commit our actual velocity, which probably accounts for some of our acceleration.  Some of it was luck/random variation.  But we think that improving our testing game, which has been ongoing and included test infrastructure stories on the backlog, probably accounts for far more.

What is our kaizen for next sprint?

The team attributed most of our acceleration to more and better testing, done sooner.  Stories that failed integration or worse, crapped out in production, sailed through both those and went straight to done.  So we chose to double down on that by trying TDD for all new code for this sprint.

We also haven’t managed to eliminate interruptions – work added mid-sprint.  No one ever does.  The cure for this is the interrupt buffer.  The average interrupt for the first five sprints has been X points so we’ll start with that.  This is something we should have been doing all along.

Taking two kaizen is not ideal.  This was driven as much by the team not wanting to wait two weeks to do something they’d already decided to do and knew how to do.  That makes it another sprint length note, again in favor of 1 week sprints.




The Dog Food Diet: Sprint 4

Sprint Goal: One instance of the new embedded technology running within the physical element.  This sprint goal should look familiar – it’s the unfulfilled part of our Sprint 3 goal.


Mirror, mirror, on the wall, what is our actual velocity?

Sprint Planning:  Backlog’s in good shape.  Our 3 sprint rolling average is (18+52+32)/3 = 34.  That’s our real, Scrum-certified velocity.  So what do we commit to?  Sigh, some habits die hard.  42 points.

Sprint Review:  We showed one instance of the new tech, running on the physical platform.  Sprint goal achieved.  We recorded velocity of 31 points.  That number looks familiar.  Hmmm, slightly less than our rolling average velocity.  Maybe we should use that?


Sprint Retrospective: On the plus side, we achieved the sprint goal.  On the minus side, we still added scope mid-sprint.  And we over-committed once again.  Our velocity is actually pretty stable, but we’re not getting better.

How did our kaizen from Sprint 3 retro work out?  We reduced, but didn’t eliminate, interrupts and the associated context switching waste.  We managed, despite losing significant capacity, to maintain our actual velocity of 30+ points.

Our kaizen for next sprint?  Commit to our actual velocity.