The Dog Food Diet: Sprint 3

Overcrowded_ferry_boat_on_Meghna_River,_BangladeshWhen the home team wins a game they’ve played poorly, the announcers often describe it as “not an artistic success”.  That’s how I feel about this project right now.  Like the overloaded river ferry on the right, we’re getting somewhere, but it ain’t pretty.  We shipped some water in Sprint 3.

Sprint Goal: The physical element being used for its designated task and one instance of the new embedded technology running within the physical element.

Sprint Planning: The product backlog is in good shape.  We come to Sprint Planning having achieved a velocity of 50 points in Sprint 2.  So what should we commit to in Sprint 3?  If you guessed 50 points, you’re right (sort of, see retrospective below).  We over-committed seriously in Sprint 2 despite having a known velocity of 18.  So what did we commit to in Sprint 3?  If you guessed “a little less than 50 points” you’re right.

Sprint Review: We showed an instance of [a thing] being built in the physical element
but did not get an instance of the new embedded technology running our skeleton app mounted in it.  The sprint goal was not met.  We achieved a velocity of 32 points.  More on that later.


Sprint Retrospective:  Anyway … we’re happy with our backlogs, which is nice, but you don’t have to be an agile savant to smell the #scrumfail in the Sprint 3 burndown chart.  We missed the sprint goal and for the third sprint in a row we achieved less than we committed to.  In this case we committed to 45 but only achieved 32.  The 45 point commitment was (marginally) defensible because we hit 50 points in Sprint 2.  But it didn’t work.  This brings us to a great sprint planning tool – the rolling average.

What would have happened if, instead of using the 50 points from Sprint 2 (the simplistic version of yesterday’s weather we should have used in Sprint 2 planning), we’d used the average of Sprint 1 and 2?  Sprint 1 – 18 points, Sprint 2 – 50 points, the average – 34 points.  Almost exactly what we got in Sprint 3.  Lesson learned.  In fact, what we will use going forward is the rolling average of the last 3 sprints.

We also backslid by adding 20 points of scope mid-sprint.  Looking back at that added scope we had a big development story, a development research story and a business research story.  The two research stories got done, the development one didn’t but they were all prioritization mistakes by our PO because they didn’t need to be done right then.

A Brief Rumination On The Beauty Of Points:  We found ourselves, at one point in this sprint, blocked on the top stories we wanted to work on.  We sat staring at the sprint backlog and somebody finally said:

What can we do to score some points today?

It took awhile, and trying to start another couple of stories that turned out to be blocked, but we found a winner and went to town.

Now, there’s nothing noble about that – as “highly motivated self-starters” we should know what to do and be doing it already.  That said, it occurred to me that there was something important exposed by this episode.  Namely, that in a non-point-based system, we would have picked something to work on, and just worked.  In a point-based system, we found the highest priority thing we could take to done and did it.

“Doing work” as we would have done in a waterfall system, creates sunk cost, that’s all.  Taking a user story to done creates business value.  And that’s what point-based accounting incentivizes – taking user stories to done.

“Scoring points” is not the way I typically think about “getting work to done”, but it’s not wrong.  If it helps you then use it.

How did our kaizen from Sprint 2 work out?  Our kaizen from sprint 2 was to keep our sprint backlog stories to 8 points and under.  In fact, we took two 8s, started but didn’t finish one, and didn’t start the other.  A wash.

Our kaizen for next sprint?  The consensus is that our velocity without interrupt-chaos would be somewhere around 40, so our kaizen for next sprint is obvious – push back on adding scope mid-sprint.

Notes on sprint length: The fact that we run 2 week sprints accounts almost entirely for the 20 points of added scope.  If the next sprint started next week instead of a week and a half from when they were added we probably could have resisted the urge to throw them into this sprint.  This is an argument for one week sprints.




The Dog Food Diet: Sprint 2

We scrambled for Sprint 1 and it ended up looking ugly.  In reality, we moved the product forward as reflected in the PO’s blessing of the sprint goal.  Still, we started without a sized backlog, as a result we overcommitted by 2X, and ended up with a burndown that screamed “FIRE ME”.

Sprint Goal: Physical elements in-place, able to accommodate the mechanical elements though with potentially large, ongoing manual intervention plus at least one monitoring function running (i.e. with at least one sensor in-place and communicating, somehow to the world outside).





Velocity:  We achieved 18 points in Sprint 1 so what should we commit to in Sprint 2?  If you guessed 18 points, you’re right.

So what did we actually commit to in Sprint 2?  If you guessed some multiple of 18 points, you’re right again.  67 to be exact.  #ScrumFail

Review: We showed the physical space with one sensor mounted and continuously uploading two values to a PHP page on an accessible web site.  Sprint goal was achieved. We recorded a velocity of 50 points.

Retrospective: We fixed some things from Sprint 1.  Product backlog was ready, we didn’t add scope mid-sprint.  We over-committed, big-time again.  50 points is an improvement from the 18 we got in Sprint 1, but it’s not 67 which is what we committed to.  Scrum Pattern: Teams that finish early accelerate faster.  That’s what the data shows, and it makes sense even in this incredibly undersized data set.  We achieved way more velocity in this sprint than Sprint 1, but because we committed to even more than that, not only is our PO pushing work to the next sprint, but we feel bad about it when we should feel good.

In other news, the new technology is a little easier to work with than we expected.  And the stories were more consistent technically, allowing us to minimize context switching and increase focus.  We talk about keeping this consistency bonus in mind when making up the sprint backlog but decide not to do anything official about it … yet.

How did our kaizen from Sprint 1 work out?  Having the backlog ready for Sprint Planning definitely made the sprint ‘feel cleaner’ but it’s not clear to anyone that this had any relationship to the bump from 18 to 50 points.

Our kaizen for the next sprint?  We took two 13 point stories into this sprint.  One of those definitely should have been split further, and 13 in general seems too risky for a team of this velocity, so our kaizen for next sprint is to not take in anything larger than an 8.

Note on sprint length.  We over-committed this sprint, same as Sprint 1, so post-retrospective we’re four weeks into this “Scrum” project and we haven’t built a proper sprint backlog.  With 1 week sprints we probably would have fixed this after week 2.

Further notes on sprint length, wherein I Praise A Tool For Expressing An Agile Principle

When I train Scrum and people ask me which tool they should use, I tell them I hate all tools equally but deign to use some of them.  Below is a Jira burndown chart from a sprint in progress (not this sprint as you can tell).  The red line is our progress, the gray line is the slope we need to meet to land this Sprint on-time.

wekendsNow this is a very small thing, but I absolutely love it to death.  Note how the gray line flattens out on that first weekend?  We configured Jira to use a standard 5 day work*** week and it’s smart enough to flatten the glide path on days when we’re not supposed to be working.

The Agile principle?  Sustainable pace. If people work the weekend on their own, that’s fine, you’ll take it.  But don’t setup any expectation that they do so, whether it’s the blatant act of over-committing, which we’re now struggling with, or the subtle pressure of a glide path that doesn’t include downtime.  Don’t be these guys!

*** If you configure your tool such that you have 7 day work weeks, turn in your Agile card now and go reflect upon your sins.

The Dog Food Diet: Sprint 1


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.


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.


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.


The Dog-Food Diet: Yummy and Scrummy


Klondike the wonder dog, strong proponent of the dog-food diet.

When you’re selling a product, the first thing people ask is do you use this product yourself?  Do you eat your own dog food.  Well, I sell Scrum and yes, I do eat my own dog food.  To be a little less snarky about it, I train Scrum and people always leave training with that trepidation about how to actually employ it in the field.  So, to show how it works, and the pitfalls that even an alleged expert runs into, I’m publishing this series of posts: The Dog Food Diet.

In these posts I’ll log and analyze the real-world management of a Scrum project, point out some of the things practitioners encounter and explain why they happen and what to do about them.   We’ll look at the progress of this project, the good, bad and ugly, from the Product Owner, Scrum Master and Team perspectives.

Unfortunately this is a stealth project so, against my usual practice of complete transparency bordering on TMI, I have to be oblique about what we’re actually doing.  In some ways this will be annoying and anodyne, in other ways it will  actually help us relate it to other projects that use different technologies and skill sets.

The system is a web-controlled, embedded device with sensors, based on new technology (i.e. not known-science).  The embedded device has some control elements (i.e. the embedded component actually DOES stuff other than sensing) in addition to simple information gathering.   There’s a web-based user-interface, cloud-hosting and a longer-term big-data element.  The overall project has mechanical/hardware elements, research elements, and a lot of software development.

Product Visioneuepofsaiuron

Any Scrum team starts with a product vision.  This product’s vision is classified but here’s the declassified version:

For people who want [to get the benefits of having a thing] our product offers the ability to create [that thing] over and over again as needed.

In contrast to [3 other specific ways of getting a thing] our product/service creates [a thing] at the same or lower cost while producing [a thing] that is higher-quality, meets [a certain regulatory requirement] and [certain non-functional requirements].



This is actually John Dillinger, not our product owner. Our PO does not wear a tie. Dillinger is a persona, but not one of our personas.

Who are we building this for?  We start with a single persona that roughly matches our Product Owner (left).  This is neither ideal, nor unusual.  It corresponds roughly to “building stuff for yourself” which is often an anti-pattern.  C’est la guerre.

To be less snarky about it, we’re building something for ourselves that we may be able to commercialize.   Think of it in manufacturing terms.  If your company build cars, for example, you may build specific tools in-house to fill the gaps between the commercial off-the-shelf tools that make up the bulk of your assembly line.  Some of those “jigs” may be interesting enough to consider commercializing.  That’s what we’re doing.

Internal ROI puts a fairly typical floor under the project.  It’s a success if it has a positive ROI even if only used in-house (i.e. never commercialized).  That ROI cuts both ways though – if the cost rises to the point where we’d have to commercialize it to stay in the black, then we need to reconsider the project.

Release Goal

The prioritized release goals for the first release are:

  1. A single installation, in-house that can remain in-use indefinitely with minimal intervention that’s lower-cost and higher-quality than the manual way we’re doing things now.
  2. Deep understanding of the new technology.
  3. Complete picture of the functional requirements of a productized version of the system, high confidence in the non-functional requirements of such a product and a roadmap and go to market strategy for a potential commercial version of the product.

In other words, we want a working prototype.

Team Launch/Working Agreements

How are we going to get this done?  These are our working agreements.

Sprint length

tapemeasureSprint length is a contentious topic.  I find myself disagreeing here with some of the most distinguished practitioners in the field so I will revisit sprint-length and its implications in every post.  We’re doing 2 week sprints.  Why?  Because I said so.  For the record, I’ve found 2 characteristics of 1 week sprints that make them less than ideal:

  • INVEST-able stories for 1 week sprints are much harder to write, and as a result you end up with many more stories on the backlog that don’t have user-visible value as the end result.  Writing lots of stories that don’t have user-visible value calls the value of Scrum itself into question.
  • The cadence of planning every Monday morning and reviewing every Friday afternoon tends to closely match the “beatings will continue until productivity improves” cadence of traditional waterfall projects.  Whether you do Monday-Friday or offset mid-week, with 1 week sprints your team members never get a break.  In 2 week sprints, the in-between weekend where there’s no sprint planning on Monday is a mental-health period.

Sprints start on Monday morning with Sprint planning, end two Friday’s hence with Sprint retrospective.


  • Sprint Planning – Monday at 10am every other week.
  • Standup – Every day at 10am, video via hangouts.
  • Review – Friday at 10am every other week.
  • Retrospective – Friday after lunch every other week.
  • Backlog refinement – as available at least once a week.


Jira for the backlogs, scrum board and burndowns.  No thought put into this – the team knows Jira and we already pay for it.

Definition of readyready

A story is ready if it meets INVEST criteria.  Dependencies that will typically need to be met within the sprint are mostly specification and procurement of parts.  We will not be doing wireframes (this may change).  Functional requirements come from the existing system, non-functional requirements to be supplied as acceptance tests.

Note on sprint length – we can spec-and-procure many more different types of parts in a 2 week sprint than a 1 week sprint.  With a 1 week sprint we’d be writing distinct specification and procurement stories paradoxically increasing our overhead in the pursuit of increased agility.

What we’ll find, on this project at least, is that we can spec, procure and write the code for many parts within a single sprint.  So in a 2 week sprint we have a story that reads like a story (“as a Josh-persona, I want to know that this sensor reading is out-of-range so that I can do something about it”) with sub-tasks that read like tasks (“spec the sensor”, “procure the sensor” and “write the code for the sensor”).  With 1 week sprints, the calendar time required to spec and procure (mostly procure) the part won’t allow us to take a story in that includes writing the code.

Definition of donedone

We have a variety of elements here and our definition of done is going to reflect that.

For physical elements:

It’s done if it works in-house and will continue to work indefinitely with little or no ongoing maintenance.  Specifically excluded are commercialization issues such as cost at volume, replicability, documentation, aesthetics or durability beyond an arbitrary lifetime of 1 year.

For mechanical:

It’s done if it works in-house and will continue to work for a year unmaintained, plus: design documents created or updated to reflect current state.  As with physical elements, aesthetics are not important.

For software:

It’s done if it works and will continue to work in test plus unit and integration tested. Deployed to production if possible, but we acknowledge that we will have to write some “deploy to production” stories as our access to production is limited by schedule to certain hours in the business day as well as by some ongoing, keep-the-lights on activity.  Correct functioning of the local user interface is not considered part of the DoD.

A peculiarity of our system is that there’s a local console on the embedded device through which a user can interact with the system as well as a remotely accessible web interface.  Our users will never see the local console so correct functioning of the local user interface, while helpful for development, is not considered part of the DoD.  This may be revisited.

**INVEST criteria for story readiness.

  • I – Immediately actionable
  • N – Negotiable
  • V – Valuable
  • E – Estimable
  • S – Small
  • T – Testable

So we’ve set the terms for starting a Scrum team going forward to realize a particular product vision.  Next week we’ll see how the first sprint worked out.