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.