Butts in Seats

I’ve always been a big fan of face-time. Not the Apple messaging app but the concept that people who speak face-to-face are exponentially more productive than people who message in “other ways”. The idea that a group of people working on the same product should be in the same room most of the time. Whiteboarding, non-verbal communication, hallway conversation. In other words – Butts in Seats.

Engineering manager ca 1995

Having said that, I’m also a big fan of Tyrannosaurus Rex, and they’re extinct. Butts in Seats is not yet as extinct as Sue the Dinosaur, but the writing is on the wall. Face to face collaboration can no longer be an expectation.

I do a lot of hiring, and the people I’m recruiting know all this. They know that old people like me want Butts in Seats. They also know that recruiting and retention are two of my biggest problems. So they bullshit me.

“It won’t be a problem” they say, and it isn’t … until it is and then having hired them it’s my problem, not theirs. I had one guy go so far as to ‘forget’ to tell me until after we hired him that he already had plans to move from a 5 minute commute to an hour plus commute. That caused plenty of grief and, as the defender of Butts in Seats, I ended up eating every bit of it myself.

So you hire someone for whom the commute “won’t be a problem”, but they need to do 10:30 once in a while. Of course, 10:30 once in a while becomes 11:00 three times a week which turns into “I need to wfh”. Pretty quickly a job that can often be fun (mine) has this daily corrosive edge to it where you drive in wondering who’s going to be pushing the Butts in Seats Boundary today and how far.

Seriously, what kind of a dick busts somebody for showing up a half hour late when we expect people to be available via Slack from 8AM to 10PM whether they’re in the office or not? Only the kind of dick who believes that a deal is a deal, and who has the support from his boss to enforce it. And let me tell you from experience, since everyone in a startup is a single point of failure, any support you think you have for enforcing Butts in Seats will disappear the minute it threatens retention. Your Jedi Manager skills should paper over the contradiction there.

In November of 2019, in the Boston market for technical talent, there is no graceful way of managing someone who isn’t meeting the Butts in Seats requirement (also known as the agreed upon and totally reasonable shared crossover in-office time of 10AM to 4PM).

What to do about it?  I’m damned if I know.  The tradeoff that seems to resonate with people is availability for flexibility.  If your off-hours time are available to the company, then your butt shouldn’t have to occupy a dedicated space at the company for a company-defined eight hour stretch.

Sure – availability for flexibility – fine. But that solution to one problem – availability – spawns a host of others, accountability, predictability, communication and the ever-popular productivity.

The real problem with Butts in Seats is its primacy – the idea that remote work is a perk that’s doled out to those who aren’t on the naughty list. I’ve managed groups where wfh was a perk, and it worked, but that moment in history has passed.

Butts in Seats is a luxury that startups can’t afford.

If the primacy of Butts in Seats is the problem, Remote First is the solution. Remote First is the organizational notion that online, non-face-to-face collaboration is the norm and face-to-face is the exception. You employ people wherever they are, and ‘figure out’ how to collaborate.

I don’t know how to do Remote First. I’m not even very good at Remote Second or Remote Third, or Remote Only In Emergencies. I hate managing remotes.** But I hate being non-competitive even more so it’s time to figure out Remote First.

** Updated 1/19 – struck through the hate managing remotes line so I can apply for jobs managing remotes.

Epic Multi-hatting


The author, multi-hatting as engineering manager and product owner

Multi-hatting is a fact of life in organizations of any size.  As long as you remain aware of what hat you’re wearing at any particular moment, life is good, right?  I’ve said as much myself.

When I talk about knowing what hat you’re wearing, I usually mean it in the sense of knowing whether or not you own the outcome, or are simply a stakeholder in someone else’s outcome.  Sadly, knowing who owns the outcome isn’t enough to do the job well.  Different roles have different outlooks.

A typical multi-hat in many organizations, large and small, is engineering manager and product owner.  Need a product owner for a team? Slap an engineering manager in there – we pay them a lot, they know the product and the team and have a little broader outlook than the troops.  But what happens when they start managing a backlog, in particular writing epics?

In the course of managing backlog – writing stories and epics – I’ve bumped up against the “what is an epic” question a lot, especially when backtracking from story to epic.  I’ll think about the story one way and infer the epic from it, create that epic, then later realize that it fits another epic that looks at the story entirely differently.  An analysis of the epics in question split them into two very clear categories – stuff I write when my head is in the code and stuff I write when my head is in the backlog.

Let’s take a real-life example from the Dog-Food-Diet series.  We want to remotely control multiple 120VAC lights and I wanted to start work on a single story called “turn AC outlet on/off”.  It was not part of an epic.  So I scanned the list of epics, didn’t see the right one and promptly wrote an epic labelled “Controllable power strip”.  Typical engineer-think – leap to the solution and generalize.  That epic describes a thing that we’re not intending to sell – a controllable power strip – rather than the intent we’re trying to accomplish within this product which is to turn lights on and off.

Fortunately, as I discovered later, there was already an epic in the backlog that neatly illustrated the point I’m trying to make here – “Hand-off control of light”.  A totally different perspective on the work.

  • Epic I wrote when my head was in the code – Controllable power strip
  • Epic I wrote when my head was in the backlog – Hands-off control of light

What you see with the first of those epics is my wearing the hat without assuming the perspective.  A “controllable power strip” isn’t an aggregation of business value, it’s a real-world thing that’s kind of like the component that we think we want to build to achieve the business goal of “turning a light on and off”.

The backlog is, first and foremost, an expression of business value.  If the things in it don’t express business value then there’s no obvious sense to the order that you build them in and you’ve lost the point to the backlog.  In other words, do your backlog items describe how you’re going to build it, or why you’re going to build it?

Note on tool use:  If we’re building a controllable power strip to achieve this function it feels weird to not categorize this story as “controllable power strip”.  JIRA offers two ways to capture the knowledge that “how” we’re going to turn lights on and off is through a controllable power strip that we’ll build into the system.  You can use components, or tags.

I chose a tag for this particular example.  We have an Android Things embedded device, an API, a web UI and the physical installation itself at the component level.  If we had a team and a separate backlog for each of these, the power strip might be a component in that backlog.  It doesn’t particularly matter as component and tag are simple attributes in JIRA, not structural features.

There ARE tools that use JIRA’s component field as a structural item.  FeatureMap comes to mind.  It’s a tool that translates back and forth between story maps and backlogs.  I like the product but … it uses the component field to group stories into features.  If you’re already using components for actual components then you’ll probably end up reorganizing things to work with it.  Going back to the Dog-Food product, for instance, and its components, a story map with columns labelled “embedded”, “web UI”, “API” and “physical installation” makes no sense whatsoever.



Learning to Love the MVP


A minimum viable spouse – plenty of room for improvement, but cheap and widely available

At the “surprise ending” of the Dog Food Diet series we ran headlong into a situation where the product became invaluable way before we’d finished the backlog.  Without aiming at it, or even thinking about it, we’d run into the Minimum Viable Product.

When I train Scrum, I run into lots of excellent people who hate the concept of MVP.  The idea of doing a “minimum” anything is repulsive to them.  They tend to be the craftsmen among us, and their philosophy of work is that whatever they build, it should be the best.  They’re the kind of people I want building my products for me.  The “minimum” in minimum viable product is like nails on a chalkboard to them.


V = R/E

It’s useful in those cases to think of MVP differently – as Maximally Valuable Product.  Value has a numerator and a denominator – revenue divided by effort – V=R/E.  If you’re prioritizing well, there comes a time in the product’s lifecycle where the revenue you get from the following incremental releases starts to decline.  If effort remains constant the “value” of that release declines relative to previous releases.


Graph of relative value delivered by sprint on the Dog Food Diet project

In The Dog Food Diet’s Sprint 7, Scrum product ownership pushed us off the edge of this cliff really abruptly.  The team, even the Product Owner, didn’t see it coming.  But in Sprint 7 the customer said, in pretty clear terms, “We’ve got this.  We’re good.  Stop helping.”.

The market told us what the minimum viable product was. By delivering just that and  no more as quickly as we could, we built the maximally valuable product for the business.

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.

The Dog Food Diet: A Product Ownership Interlude


As Dilbert once said (sort of) “Welcome to product management.  Two drink minimum.”  At this point, 6 sprints into the project our release burndown looks something like this:

Screen Shot 2017-12-20 at 6.53.15 PM

Aaaaaaannnnnnyyyyyyyhooo …. 

This release is going to happen, probably sometime around Sprint 10.  There is no question that the product works and the functional release goals will be substantially met.  There are stories that have appeared out of nowhere and gone to the top of the backlog, stories that seemed critical that have fallen to the bottom of the backlog and stories that have failed in execution and had to be reworked from scratch.

Given that this is an internal release there’s little angst that goes into “calling it done”.  The more interesting questions revolve around what comes next.  After this release we’ll have something with a positive ROI when sold to one customer, us.  What about customers who aren’t “us”?

Up to this point we’ve put a small handful of PO stories on the backlog.  Generating lean canvas for the product, maintaining an up-to-date bill of materials to give us an upper-limit unit cost, and some better-than-internal documentation.  Now our PO needs to build a decision about whether or not to sell the product to people who aren’t “us”.

We’ve reached a commercialize-or-not decision for the product.  The team, including the PO, desperately wants to commercialize.  You want them to want this.  “Purpose” is a key part of motivation (Autonomy, Mastery, Purpose) and if your team doesn’t feel they are serving a big, worthwhile purpose then they won’t perform well.  But this means that if the team and PO just sit down and talk about whether or not to commercialize all you’ll hear is various flavors of “Hell yeah!”.  We need metrics.

Because of the company’s unique (alright not-so-unique) position, “time to break-even” and “maximum exposure before break-even” put hard limits on the investment we can make in the product.  A version of the product that takes too long to break even, or takes too much investment to launch at all would require the company to bring in a round of investment, which pushes the decision up a level from the PO/Management Team level where it lives now.  Again, typical constraints.

Getting those metrics done well, and being hard-headed about them is top priority.  What do we need to get those metrics?  For this particular product:

  • Cost of labor to build this.  This should fall out from a well-constructed product backlog and the velocity metrics we’ve already produced.
  • Legal and regulatory.  There are expensive regulations that need to be met to commercialize this, we know what they are, we just need hard numbers and timelines about how to meet them.
  • Cost of go-to-market.  Given a product that meets regulatory and does things people will pay for, what does it cost us to get them to buy enough of it that we reach break-even without breaking our total investment ceiling?

Second priority is the potential return on this investment.  We split this into two questions that will look familiar to fans of Lean Customer Development:

  • Does anyone besides us have the problem this product solves?
  • How many people have this problem and what will they pay to solve it?

Scrum Implications of Commercialization Decision

2drink.pngWhat does all this mean for the team?  In large companies, except for the BOM and people-cost, all this “business stuff” would disappear into a black hole of decision-making populated by business trolls doing exclusively business stuff.  But we’re a small company and we need to do all this with pretty much the same team that’s actually building the product.

We’ll use a typical structure that enables swarming.  Our PO will structure the Lean Customer Development stories, and the team/PO will figure out how to get them done and run them off the same Sprint Backlog that we build the product from.

On top of all that, the team realizes that given the amount of work and sheer calendar time that needs to go into this decision, we’re very late getting started.  Customer development interviews, in particular, eat calendar time.  We’ve already started Sprint 6, with almost exclusively product development stories and won’t want to wait two weeks to start on commercialization stories.  Fortunately, our kaizen from Sprint 5 was to implement the interrupt buffer pattern and we now have 10 points of interrupt we can draw from without angst.

So What Do We Do First?

There’s a bunch of stuff we need to do to build this commercialization decision.  That stuff becomes stories on our product backlog.  Our team is doing backlog refinement weekly, so our PO needs to write those stories, get them sized and prioritized, recognizing that he has only 10 points of interrupt for this sprint where he can jam in unplanned work.

Notes on sprint length (are you bored with sprint length yet?). This once again argues for one week sprints over two weeks.   Realizing that it will take at least a couple of days to create new PO stories, we could easily put off starting on them until next week in a one week sprint system.  In a two-week sprint system we’re forced to use interrupt buffer to accommodate the urgency of these PO stories.






The Dog Food Diet: Sprint 6

messywiresSprint Goal: Cleanup installed hardware and implement one internal-feedback controlled function.

We’ve explicitly excluded physical aesthetics from this first release but there are limits to everything and the mess of wires in production threaten to make trouble down the road.  Add to that the fact that we need to take production apart to enable some of the control-function stories (wires that weren’t brought out to an accessible terminal) and it makes sense for this to be a goal.   Feedback controlled function is the embedded system making an intelligent, sensor-based, not schedule-based, local decision to “do something”.

Sprint Planning:  Our velocity is 54 and we take 54, including an interrupt buffer which we eyeball at 10 points.

Everyone’s anxious that the product backlog is thinning out and starting to be dominated by business value research stories, bigger, more difficult technical stories and stories that apply more strongly to a commercial version of the product than to an in-house version.  A decision point is looming for our PO structure.

Sprint Review: We showed the radically reorganized installed hardware and a control function directed by internal sensor feedback.   The sprint goal was met, and with room to spare.

Screen Shot 2017-12-20 at 6.41.10 PM

Retrospective:  Lots to talk about at this retro.  Looking at the chart, we flat-lined for the first three days, got on the curve then flat-lined again.  We’re repeating a pattern of floating “above the curve” for most of the sprint and bringing it in, if we do, at the end of the second week.  This could mean we’re taking in stories that are too big but looking at the second half of the burndown chart report we see that the stories we burned were all ones, twos and threes so we’re good there.

This floating above the curve phenomenon is a builtin tension to doing almost anything, by almost any methodology.  Jeff Sutherland always compares burning down work to landing an airplane which is a great visual analogy.   The biggest problem with floating above the curve as a way of life is that it has a completely ill effect on both the Scrum Master and Product Owner.  Your SM and PO can have confidence that you’ll land the plane, but it will be based on faith, and history, not on the current state of the chart.  There may be a happiness metric benefit to, every now and then, taking a quick win at the start of the sprint.

Despite our velocity, we also had three dangling stories that fell into two camps.  One was a story that was complete except for deployment to production.  Remember, like any ongoing business we’re limited in our access to production and the size of the window we can bring it down.

The other was a pair of stories having to do with controlling a motor.  The team fears it.  It’s messy and risky so no one wants to touch it.  It was probably a mistake to put them at the end of the sprint backlog where they’d be easier to punt.  We’ll swarm at least one of them at the beginning of Sprint 7.

Jira note: We took in two stories about the same physical part – a three pointer to jury-rig it to get another week out of it, and a five pointer to replace it entirely.  We ended up doing the five pointer on day eight without needing to do the jury-rig so we removed the three pointer from the sprint.  In the burndown chart that descoping is represented just like completed work, but Jira is smart enough not to count it toward our velocity.

How did our kaizen from Sprint 5 work out, part 1?  TDD – TDD was epic.  The team loves it so much we started looking at BDD.  Note that like most everything that seems radical and new, BDD is actually a decade old now.

When we took this kaizen, we estimated it at 5 points.  Then I realized that it was stupid to size this kaizen.  That’s what you see on day 5 where five points disappear from the scope of the sprint.  My thinking here went as follows.  TDD requires effort, but that effort for each story is part of the story itself, not a separately sized thing.  And theoretically it should be speeding us up, so if we count velocity for doing TDD and get a velocity bump on the individual stories, we’ll be double-counting one kaizen which we’ll have to “give back” next sprint when it’s not the kaizen anymore.

So put the kaizen on the backlog, but don’t size it because it doesn’t directly create business value.

How did our kaizen from Sprint 5 work out, part 2?  The interrupt buffer came in handy almost immediately.  On the fifth day of the sprint we had a production emergency, three point story.  So we added a three point story to the sprint backlog.  But we want those three points to “come out of the interrupt buffer”.  So we reduced the point estimate on the interrupt buffer to seven.  That’s the spike that shows up on day 5.  Adding three points of scope for the new stories, subtracting three points of scope from the interrupt buffer.  And when we burned down those three points on the same day, we end up, as we expect, on the same slope as if we’d just burned a three-pointer from the sprint backlog.


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.

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.