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.

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: