Over the last three years, I have occasionally had the strange pleasure of running the @howaboutwe development process. I am non-technical and have compensated by trying to construct and refine an engineering process that yields high productivity, low debt, and high morale.
The center of the engineering process is the two-week sprint. This is perhaps the most carefully crafted process in our entire organization.
To start, I’d like to outline a few general principles that every engineer in your organization should understand, uphold, and come to trust are being upheld by everyone else.
- Reason pummels dogma:
I hate dogma. I find it nauseating. And to an equal extent, I adore reason. Reason seems to me like the antithesis to pride, ego, prejudice, and waste. We gather data. We outline options. We ensure that we understand the pros and cons. We weigh predicted value and value loss and then we choose. We don’t always choose through complete consensus, because attaining consensus is itself a cost that we consider–and we’re just as cognizant of the morale loss that comes from lack of consensus. We might be wrong, but we try earnestly to be reasonable and transparent about what motivates our reasoning. Reason wins over dogma every time in my shop.
- Perfection is a cardinal sin:
That’s right, a sin–and I don’t even believe in “sin.” This isn’t an assertion that comes naturally to me; like a lot of people in this industry, I’m a perfectionist at heart. I like to leave my desk with literally nothing on it at the end of the day. I hunt inbox zero like it’s the goddamn elixir of immortality.
And yet, every day we ship features that are imperfect–I know they are imperfect. I make 100 decisions every day that stab the perfectionist in me. Yes, that email template is good enough (even though I hate those buttons). Yes, ship that new search interface (even though there are six known bugs). If perfectionism rears its glistening silver head in the midst of your engineering process, you will suffer. Do not allow this.
Here’s why: Perfection applied to any particularity will inevitably annihilate any possible perfection in the whole. Engineers sometimes understand this perfectly and implicitly, like the words of a well-worn bible. Other times, they are like me and find this larger view to be pure pain and suffering. Both positions are noble. But only the belief that perfectionism is a sin should have a place in your organization.
- Every hour is well spent or wasted:
Every hour spent is reflective of a strategic decision. The sum total of all strategic decisions determines, in large part, the success of our work. Every engineer should feel that they are constantly making choices about how to offer the most value. It is the job of your entire engineering team to make sure that each person is offering the most possible value with each hour.
Ultimately, this makes everyone happier, more fulfilled, and more productive. Another way of thinking about this is: Identify and avoid small and large black holes aggressively. It is the tendency of many engineers to want to solve a problem no matter what it takes–again, a noble way of being, but a propensity that should be completely avoided for the sake of overall value creation.
- Prioritization and freedom are brothers, not enemies:
Intense prioritization of what is going to be built can easily feel to the dev team like some top-down bureaucratic bullshit: the opposite of freedom. And engineers love freedom, as they should. But I categorically disagree with the idea that prioritization and freedom are in opposition; In fact, I think this is a destructive idea.
If I am alone on an island, well-used freedom looks something like this: I decide what my goals are (survival, let’s say). Then I think through options about how to achieve these goals (which would include collecting wood and hunting whales). Then I weigh costs and benefits and decide on how to use my time and energy (presumably to collect wood). Collecting wood in this instance feels like–and truly is–a good use of my freedom.
In a company, no one is alone on an island. That means that one cannot understand all the options about how to use one’s freedom, nor can one understand all the costs and benefits implied by that use. The prioritization process must be collaborative.
But a collaborative prioritization process doesn’t imply that the act of doing what’s next on the roadmap isn’t any less free than collecting wood. It is the responsibility of the company leaders to ensure that the prioritization process involves listening deeply to everyone’s best ideas and then transparently weighing all possible benefits and costs. A roadmap is a collective guide for how each employee should use their freedom.
In the next section of this series I’m going to outline the details of the @howaboutwe engineering sprint, a functional manifestation of the principles I just described.
Now that I’ve covered the principles behind development sprints, I’ll explain the brass tacks of sprint planning. I’ll begin by discussing team structure and the sprint schedule, and then turn to the intricacies of story writing.
My engineers work in small teams of 3-5 members each. Every team is focused on a particular product and platform. Currently we have the following teams:
- Dating Server Side (includes website, mobile web, api, backend)
- Dating Mobile
- Couples Server Side
We think of our dev schedule in two-week increments. These are our sprints. The calendar runs something like this:
Developers: Conclude previous sprint with team retrospective
Product Managers and Team Leads: Run Sprint Planning Meeting with dev teams
Developers: Sprint begins!
Developers: Daily Standup meetings; check-in as needed.
Product Managers and Team Leads: Prepare for the next sprint
If there was a single thing I wish someone had taught me early on in my time as a product leader it is the art of story writing. It’s not hard, but it’s easy to screw up. And it is vital. The most important day-to-day decisions your organization is making about its product happen through story writing. Before I go any further, I’ll define what I mean by “story.”
A story is a brief description of something you want to ship to users. A story includes all the details an engineer needs in order to make smart decisions about how to implement it. This includes design assets and written specs outlining how the feature should work.
Stories can be as simple as “change the label on this button” or as complex as “create an ABC test for our baseline search algorithm in which Group A gets the following results x, Group B gets these results y, and Group C gets these results z.”
What’s critical is that each story:
- can stand on its own; if it has dependencies, combine them into one story
- can be delivered to QA and tested
- can be shipped to production (even if it has to be paddocked in some way)
Stories are the building blocks of product development. In the aggregate, the stories you ship are a representation of your organization’s strategy. A hundred micro-errors at the story level lead to massive organizational lethargy. Stories define the molecular structure of your company’s leanness.
Your product managers and engineers need to be cutthroat in their decisions about what to build and what not to build. Every feature on your roadmap could be built in radically different amounts of time. You could spend a year building out a new search experience–or a month. The stories you write about this feature will define this difference. Everything is about opportunity cost; yes, this story will make this feature better, but what else could we be making in this same time period?
The more specific your stories are, the more they will help engineers to understand the intended scope of the project. This is generally a good thing. However, hopefully your engineers are creative, smart, independent thinkers with a deep interest in the product they are making–so when stories are overwritten it can feel wasteful and demoralizing. This is a fine balance.
The product manager for a team needs to prepare for each upcoming sprint, which means ensuring that the Sprint Planning Meeting involves a smooth review of a prioritized and defined list of stories. Achieving this smoothness, prioritization, and definition is not easy. Here’s how we do it.
- First, the product manager tries to construct their best bet about what should be built in the next two weeks based on the broad organizational roadmap (we do quarterly roadmapping, requests from marketing and sales, requests from engineering via our CTO and Team Leads, an understanding of what is unblocked by design processes and dev planning processes, and (if we’re being honest) the whims of the organizational leadership.
- Next, the product manager presents this broad plan–usually on the Thursday prior to the next sprint–to applicable leadership. In our company I am both co-CEO and Head of Product, so that’s easy: our product manager just presents to me. (I am lucky to have the most remarkable VP of Product ever; she manages all our teams, so it’s a one-on-one meeting for us.)
- The product manager then goes through a similar process with our CTO and Engineering Team Leads, sometimes simultaneously. This means reviewing all stories and calling out what needs advanced technical planning. This includes stories that imply database schema changes, difficult algorithmic moments, significant architectural choices, etc.
- Finally, the CTO and Team Leads engage in a process of calling together applicable stakeholders (devs as needed, data architect, and so on) before sprint planning to hash out implementation details. The goal of this process is preparation for sprint planning; ideally most major technical decisions have either already been made, or if unmade, have been clearly identified as needing careful attention during the building process.
Bugs and features draw from the same limited pool of resources. For this reason, my belief is that bugs should be considered and written as stories just like features. Likewise with technical chores. Likewise with marketing requests. Anything that is going to require engineering resources should be reduced into the common unit of a story.
The power of this approach is that it requires you to make hard resource allocation choices. If you have separate processes for prioritizing bugs and technical chores then you are subtly shirking the difficult questions about what is most important. This is a temptation the perfectionist will need to fight.
One of the most challenging things about this process is ensuring that all relevant perspectives are included in the prioritization process. I consider it my job as Head of Product (and, incidentally, as co-CEO) to understand and mediate all of these perspectives and make the tough choices.
Listening and responding thoughtfully is the most important way that people build trust. I am counting on everyone who will execute these decisions to trust that I have incorporated all relevant perspectives and am making smart, balanced choices. People should feel that they are heard and that what they are doing is the best application of their time and intelligence. If the particular task they are doing is kind of annoying, people should trust that their annoyance is understood and has been factored into our estimation of the cost of that task. Too much grunt work kills morale, which kills productivity and increases recruiting costs. And it is also the responsibility of everyone to question things when they feel dumb.
The result you want from this process is a feeling in the whole group that that their precious assets–time, thought, creativity, care, sheer will–are being truly valued and effectively utilized. Of course, the other ideal result is that this is actually true.
This meeting is facilitated by the Product Manager. It is 45-90 minutes long, depending on the team. Preparation for this meeting will dictate its success, so if you spaced out during the previous section, well, get ready for a painful meeting.
The important thing to note is that the stories reviewed in the Sprint Planning Meeting represent a prioritized list of what the company–which very much includes every person in it–believes are the most important things to be built in the next two weeks.
- Pivotal Tracker, the story-tracking software we use, is projected on a wall where everyone in the meeting can see it.
- Periodically, about every two or three sprints, the meeting begins with a quick overview of the larger-scale roadmap.
- We begin by reviewing stories currently in progress.
- Next, we go through the “Backlog” of stories.
- All necessary preparation with devs, designers, and product leaders has happened to ensure that these stories–as much as possible–are clearly conceived, listed in a prioritized order, and unblocked (meaning, for instance, that design assets are ready).
For each story, we do the following:
- Read it aloud. You can rotate who reads each story to keep everyone sharp and involved.
- Discuss any peculiarities or special considerations.
- Throw point estimates for the story as a group. (More on this below.)
“This is stupid.” “That’s now how we should do it.” These are all healthy reactions to stories, even if not healthily articulated, by an engaged group. Hopefully most of this has already been handled through many rounds of dev review, but it’s inevitable that people can be highly critical in Sprint Planning Meetings. The role of the facilitator is to figure out on the fly whether the issue can be worked out in the meeting in under 3-5 minutes without creating too much conflict. If it looks like it’s going to be a hornet’s nest, offline the issue and move on.
Estimating stories works a little like rock, paper, scissors. We bring up a story, and the devs use their fingers to simultaneously throw a point estimate: “zero points” is a fist; two fingers is a two; four fingers is a four, and so on. We use the 0,1,2,4,8 point scale.
There are two schools of thought that I know of regarding points. They are:
- Points don’t refer to specific measures of time. One way to use points is to reflect the team’s sense of how difficult a story is. Over time, by watching our “velocity”–points per time period–we get a sense of our efficacy relative to the past. By keeping the points relative we can use our velocity to mark progress. This requires very consistent teams over time and a general belief in magical forces (I think).
- Points represent specific amounts of time. The other approach is to say, well, zero points is something that will take under 30 minutes, one point is an hour or two, two points is about a day, four points is two or three days, and eight points is a big fucking mess.
We use the second approach.
Bugs Are Stories: We believe in assigning points to everything–including bugs and chores. Some people think points distort the point values of the original stories that generated the bugs and subtly promote sloppy work. I believe this is true, but I also believe that by counting bugs as stories you require yourself to make hard decisions between perfecting features and building new ones. I count bugs as stories.
Spikes are an Exploratory Tool: One useful tactic is to turn from exact descriptions of how something should be done into more general “Spike” stories, where the story becomes an exploration to actually determine the best way to attack a given problem. Spikes (which can also be thought of as “Discovery Stories”) should be time-capped to no more than two points. The outcome of the Spike is the writing of stories for implementation in the next sprint.
Don’t Get Lost In Implementation Details: Another challenge is figuring how many of the implementation details of a story should be worked out in the Sprint Planning Meeting. My general approach here is something like: “about half.”
For the most part, devs can creatively solve granular problems as they are coding. The purpose of the Sprint Planning Meeting is to convey from a product perspective what the result of their work should be, and to estimate how long it will take to achieve that result. Implementation details can get hammered out later.
That said, major architectural decisions require extensive group processes. Further, implementation details frequently affect estimations and how stories are written. The facilitating project manager will need to mediate this on-the-fly. Discussing implementation details even cursorily can support knowledge sharing and save lots of time later, so don’t skip it entirely. Find a way to get into it without getting mired in the granularities.
Coordinate Specialists Beforehand: Another challenge is the coordination of different types of engineers: Front-end, back-end, data architects, data scientists, and so on. Solutions here depend very much on the structure of your team. We have a generally full-stack, highly integrated team, which makes this coordination both easier (not that much needed) and harder (it’s tough to integrate the occasional needs for intense specialization).
Whatever your team looks like, coordinate beforehand. The Sprint Planning Meeting is a terrible place to mediate complex decision-making–that needs a smaller, more focused group.
Sprint Waterlines: At some point we’ve gone through enough stories to feel pretty sure that we’re past the “what we can do in two weeks” line. The product manager calls this out. She somewhat arbitrarily makes a guess in the tracker about where to put the “Sprint Waterline”–the team’s goal for the following two weeks. There is sometimes discussion and movement of the waterline. Then the entire team simultaneously throws a “Fist to Five”, a fist being “No friggin way we can do this, absolutely not” and five fingers being “Yup, I’m completely positive we can do that unless an act of god interferes, and even then.” We play around with the location of the Waterline until everyone comfortably throws fours and above. And that’s our goal for the next two weeks.
Time to build.
You are reading Unblocked: A Guide To Making Things People Love, a series in seven parts.
Part 2: Value-Driven Product Development: Using Value Propositions To Build A Rigorous Product Roadmap
[Image: Flickr user Hans Põldoja]