The Dog Food Diet: Sprint 1

releasehounds1

The team leaving Sprint Planning meeting.  From left, mounted, our Scrum Master and Product Owner.

Release the hounds!  We have a product vision and a team working to realize that vision.  Let’s see how they got out of the gate.

In an ideal world, the first sprint for a fresh team unrolls like the first 10 plays of a Joe Montana-led 49er’s team back in the 80s.  We roll down the field racking up first downs and eventually score a touchdown while barely acknowledging the other team’s existence.

In real life, IRL as the kids like to say, you almost never start fresh.  The team comes together from ‘doing other stuff’, some of the team is already working on the product, and if you’re just starting Scrum you’re getting people on board with the methodology.  These challenges have consequences and that’s where we are.

Sprint 1

Goal: Get the physical and mechanical elements in place to support the first installation.

There is a base lump of physical stuff that needs to exist to support a working prototype.  It needs to fit a physical form-factor and has some functional requirements like access and environmental control.  The physical and mechanical bits are a weakness in the team so there’s no question this is a right-sized, perhaps even aggressive goal for Sprint 1.

Velocity:  Total guess here, but we’re going with 40 points as our initial velocity based on a reference story that usually takes us less than half a day.  It’s a nice number, but of absolutely no use to us because ….

Sprint Backlog: Ummmmmm …. <see retrospective below>

Sprint Review: The goal of the sprint was, for the most part, met.  Physical requirements of the working prototype were in place and the base for an installation of the control and monitoring elements was established.  Dangling elements largely consisted of things that needed to be bought that hadn’t arrived in time.  In the PO’s estimation they didn’t materially detract from the goal.

Sprint Retrospective:  The PO says we met the sprint goal so everything’s great, right?  Not even close.  Check out the Jira burndown chart below.  If your burndowns look like this, you’re doing it wrong.  Let’s dissect the sprint reports and tease out the ScrumFail.

sprint1burndownchart

Just looking at the burndown chart, it looks like we took no work at sprint planning, sat on our hands for eight days, added a bunch of scope on day 9, added more scope on day 10, did some work on day 11, did some more work on day 12, then did nothing on days 13 and 14.  Who works like that?  Even so, we recorded a velocity of 18 points.

If we look at the second half of the Jira burndown report, we see what actually happened. Sprint planning consisted of taking the existing task list, imposing a rough ordering, and skipping the sizing.  We started with a boatload of issues, launched right into them but didn’t size them until one week into the sprint.  Jira reports this as a scope change of plus-40 on day 9 of our 14 day sprint.  We also burned down a number of issues before sizing them.

sprint1burndownlist

Note on Scrum burndown charts.  When you burn down hours, you’re burning down time on task.  There’s no hint of whether that time produced anything.  See here for the Mandatory Dilbert link.  When you burn down points, you’re burning down delivery of user-visible value.  The latter matters.  The former is about as useful in product development as a sundial

Week 1 was the enthusiasm stage.  Getting started was all-consuming. It wasn’t until week 2 that the SM and PO woke up and realized that they were foregoing a learning opportunity and, belatedly, fixed up both the backlogs.  Not good but not fatal either.

This is not unusual for a team starting with Scrum.  The team was working on some of this stuff already, had Scrum imposed on it on-the-fly and the SM/PO combination didn’t get its act together backlog-wise until the second week.  It happens.

Our kaizen for the next sprint?  Backlog appropriately groomed for next sprint planning.

Note on sprint length.  If we were working on 1 week sprints we would have ended Sprint 1 on Day 7 with zero work committed, zero delivered and a useless velocity metric.  On the plus side, we would have woken up on Day 8 staring at a total ScrumFail and fixed it earlier than we actually did with our 2 week sprint.  If we were a bigger organization, the second week of this ScrumFail would likely have been an ugly reconsideration of the entire Scrum thing.

 

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:

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: