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.

Developers, Ecosystems, the Universe and Everything, i.e. 42

Someone once said that “at a startup you’re not competing with other startups, you’re competing with apathy”.  I’ve found this to be true over a long stretch in startup-land.  I never got crushed by competition, but against apathy my batting average is sub-Mendoza line.  I think about that a lot.  If you and I both jump in a lake, the fact that I floated longer than you did doesn’t matter much if we both drown.

greenhouseWhat brings this to mind is a discussion I had at a team dinner with the estimable Citizen Sigmund of Scrum Inc.  She mentioned some challenges she was having coaching Scrum with a particular team at a company out in a lightly populated section of the state.  The team-dynamics she described reminded me of a difference I always see between teams in hothouse ecosystems like Boston, New York, Seattle and San Francisco and those outside the hothouses.

In a nutshell,  even among comparable companies, it’s almost always more difficult to get teams to buy into tactical Scrum outside the hothouse.  And this is true even when these teams are failing and desperately unhappy.  They often seem like they’d rather fail in a way that’s familiar to them than succeed doing things differently.

sumoThe third leg of this observation, was a dark data point I gathered a lonnnnngggggg time ago.  Back in the day I figure skated.  Yes, it was often as funny as it sounds.  And having done it for many years, I had a certain impression of how I looked out there, how good I was.  Then I saw myself on video.

Oh, ignorance was certainly bliss.  When I skated, it felt good, so it must look good … it must be good.  It wasn’t.  Same thing happens to dev teams in the wild.  They get into a way of working and the paychecks keep coming so it must be good.  But it often isn’t and they have NO idea because they’re not surrounded by world-class competition.

How does this relate to startups and apathy?  It’s the age-old question of how do you know when you’re succeeding.  Startups often measure themselves against each other – how much money we’ve raised for example – when what they need to measure their success against is their market’s innate inclination to DO NOTHING.

When I skated, I knew what good skating looked like from seeing good skaters in person, and on TV, but I didn’t know what I looked like.  Devs in the wild have the opposite problem.  They know what they look like, but they don’t know what good devs look like.  They only have each other to refer to, not a wider pool of people doing the same thing in different ways.

What does it all mean?  Measure things, don’t assume you’re doing well as I did on the ice before the age of video.  Measure the right things, don’t be That Guy sitting around at Starbucks bragging about how much money your company raised.  And finally, compare your, your team’s, and your company’s metrics to the best in the world, not just to the people and companies in your immediate vicinity.



Some Concrete Things To Think About With Technical Co-Founders

I talk to a fair number of people who are looking for technical co-founders to help them build web-based businesses.  When we get to the point where we decide not to work together, the smart ones always ask me if I have any advice for them moving forward.  And I do.  Here it is.


It’s tempting to think of yourself as the next Steve Jobs and to imagine that the bearded man you’re having coffee with later today is the next Steve Wozniak.  Not happening.  You’re not Steve Jobs and that guy you met on cofounderslab is just an ungroomed jumble of untested technical skills, social awkwardness and unknowable cofounder potential.  The question is – What can he do for you in the next 18 months?

If I were a non-technical cofounder building a web app from scratch I’d have two demands of a technical cofounder, or contract house. First, that they build good stuff – i.e. that the product work and that it looks good.  Duh. Second, that they can create, and from day one deploy to, a continuous integration infrastructure – aka immutable infrastructure.

“CI from day one” means throwing away a little bit of time in the beginning setting it up, and dedicating a little bit of cash burn in the long run. For your purposes, CI is a system that can take a change to a web site as committed to source control, run automated tests against it, raise a flag if the tests fail, or deploy successfully to staging/production if they pass.


Think of your infrastructure as a sort of 3D printer that takes your designs and turns them into real-world objects.  Your business, at heart, is a machine for producing iterations of a web site.  If it can do that quickly, at high quality, it may be worth something someday.

If your business produces iterations of a web site that take days to code trivial changes and those changes fail deployment every single time you go to production then what you’ve built is not a business – it’s a learning experience.

What you will get if you talk to the young and ambitious crowd is a lot of people who:

  • can work within an infrastructure that someone else has set up OR
  • can set up a one-off web site from scratch in the cloud using a bare-naked Linux instance with a bunch of stuff configured on it and can redeploy manually, or via source control (not deployment packaging).

They have no idea how to setup something that multiple people can contribute to, that automates testing, and that deploys correctly every single time.


If you set up immutable infrastructure, the bus-factor for your technical co-founder goes to zero, which is something that you desperately want and that they shouldn’t fear.  But even better, when you have an infrastructure that works, you can profitably employ all those cheap and available people who can only do good work within a working infrastructure – e.g. junior web devs, recent Startup Institute grads …

And if you’re thinking about outsourcing – you must, must, must own your own infrastructure, every little bit of it including DNS.  And think very carefully about the access rights and take continuous backups.  Get a friend to setup the accounts if you have to, but don’t rely on your outsourcer to do it, and don’t have them as administrative owners of any piece of it.  Having your outsourcer provision your infrastructure works great right up until the first time the two of you disagree about money.  Ask me how I know this …

I would also spend some time reading up on the concept of a Scrum Product Owner, even if you don’t intend to ‘do scrum’. As founder you have the ultimate authority over everything, but some of these responsibilities you’ll entrust to people you collaborate with. After all, you don’t want to micro-manage.  That’s fine, but the PO concept defines the set of things that, as “product person”, you need to own and not compromise about.  I’ve found over the years that successful companies, even ones that don’t do Scrum, concentrate the same set of responsibilities within product management that Scrum entrusts to Product Owner.

And, from day one, implement the concept of the sprint demo. You will find, talking with devs, that you’ll ask the question “Is it done?” and they’ll say “Yup, X, Y and Z are all set.” Only later will you discover that “it” and “X, Y and Z” are different things. If it’s done, prove it, and if you can’t show it, it ain’t done. This is HUGELY important with outsourcers.  The sprint demo is about quality and accountability.  Live it.

Notice that I haven’t said anything about stack.  Frankly I mostly don’t care about the stack and you shouldn’t either. RoR with some javascript framework seems to be a standard thing, and well-known among the offshores, but there’s a dozen good ways to write a web app these days.  In any case, whatever stack I recommended today would be wrong tomorrow.  Immutable infrastructure, on the other hand, is a sine qua non from this point forward.

In a nutshell, here’s my advice:

  • Immutable infrastructure
  • Own your own infrastructure
  • Be a Product Owner
  • Enforce the Sprint Demo

And remember, easy for YOU to do is easy for ME to say.  Ahh, the joy of blogging.

Scrum Point Accounting for Unfinished Stories

Here’s one for the Scrum nerds out there.  Working with Joe Justice of Wikispeed, I cooked this post up because this is the last time I want to have to refigure this out from scratch.

beancounterThere’s a point that comes up every time I train or coach Scrum teams related to whether or not you re-estimate a story that was unfinished at the end of last sprint when you take it into the next sprint.  It drives me crazy because I personally despise hour-based project management accounting and these sorts of questions evoke bad memories of waterfall projects and PMP project managers.  I’m also really bad at math.

So let’s take a look at what happens when a story is half-finished and carried over to the next sprint by teams using different accounting methods.


The chart above shows the burndown for a hypothetical 40 point release (eight  5 point stories) by three different 10 point teams.  All three teams completed the release.  Team 1, in blue, burned down the project smoothly 10 points per sprint.  Don’t laugh, it could happen!  No accounting issue there.

Team 2 didn’t complete one of the 5 point stories in sprint 1 and got 0 points for it in that sprint.  They took it into Sprint 2 as a 5 point story, completed it along with two more 5 point stories.  They recorded 15 points of velocity for Sprint 2 and got back on the ideal burndown for the rest of the release, burning those 40 points down to 0.

Team 3 also didn’t complete one of the 5 point stories in sprint 1.  They also took that story into Sprint 2, but re-estimated it at 2 points.  They completed that incomplete story, now valued at 2 points along with two 5 point stories the same as Team 2.  But because they re-estimated the remaining work on the unfinished 5 pointer as 2 points, they recorded only 12 points of velocity where Team 2 recorded 15 for the exact same amount of work.  Essentially, the release lost 3 points of work.


The method team 3 used, and the one I’ve advocated up until recently, I call Shrinkage.  That’s because the amount of points recorded to complete the release goes from 40 to 37 when the unfinished 5 point story gets re-estimated.  3 points simply disappear from the release.  I like it for some very tactical, team psychology, Scrum Master oriented reasons:

  • It forces us to be honest about the work
  • It helps teams avoid the trap of simply taking the product backlog estimate of a story into the sprint backlog
  • It reinforces the notion that incomplete work is waste
  • It exercises the team’s relative sizing muscle

Conservation of Points

The method of team 2, where they didn’t re-estimate the remaining work but simply took the story into the next sprint at the original estimate I call Conservation of Points.  The three points of work on the unfinished story in Sprint 1 are carried over into Sprint 2 and accounted as Sprint 2 velocity even though the work was done in Sprint 1.  No points disappear from the release.


I recommend using Conservation of Points now for one, and only one reason.  In a Shrinkage model, in order for the release burndown to continue to fulfill its purpose, the product owner needs to account for the lost points.  The PO needs to shift the whole curve down, so that instead of starting at 40 points for the release, it starts instead at 37.  Some automated tools may support this, but in a manual situation or where you’re tracking in Excel this can be a real pain in the neck and stuff that’s a pain in the neck ends up not getting done.

UPDATE: As commenter Nigel Thurlow points out, if you use Conservation of Points you must use a rolling average for velocity in Sprint Planning.  Using the single data point of “last sprint’s velocity” as your sprint planning velocity (rather than a rolling average) will leave you chasing bad data up and down the burndown chart, essentially amplifying the negative effects of unfinished stories.


Many thanks to Joe Justice of Wikispeed and my friends at GE Power and Water in Mumbai who inspired me to finally write this down.