What makes a great user story?

A great user story should be:

• “I” ndependent (of all others)
• “N” egotiable (not a specific contract for features)
• “V” aluable (or vertical)
• “E” stimable (to a good approximation)
• “S” mall (so as to fit within an iteration)
• “T” estable (in principle, even if there isn’t a test for it yet)

A good reminder, especially as you start your 2017 planning.

A great (and relatively old) post on Ben Horowitz’s site outlines the differences between a peacetime CEO and a wartime CEO:

Peacetime CEO focuses on the big picture and empowers her people to make detailed decisions. Wartime CEO cares about a speck of dust on a gnat’s ass if it interferes with the prime directive.

Peacetime CEO spends time defining the culture. Wartime CEO lets the war define the culture.

Peacetime CEO always has a contingency plan. Wartime CEO knows that sometimes you gotta roll a hard six.

Peacetime CEO strives not to use profanity. Wartime CEO sometimes uses profanity purposefully.

Peacetime CEO thinks of the competition as other ships in a big ocean that may never engage. Wartime CEO thinks the competition is sneaking into her house and trying to kidnap her children.

Peacetime CEO aims to expand the market. Wartime CEO aims to win the market.

A great read for product managers. Sometimes you should let the team decide if they want to use Scrum or Kanban, and sometimes you just need to get the work done regardless.

Read: Peacetime CEO/Wartime CEO

The weekly update is one of the most effective ways of keeping teams aligned and coordinated. This weekly update template guarantees it will get read.

How often do you think about team coordination, or alignment between teams?

If you’re like me, it’s constantly on your mind.

Team coordination and alignment are one of the most-discussed topics in sprint retrospectives. And every team I’ve been on or led comes out of it with the solution of more communication.

Easy solution: have more meetings or send more emails!

Barf. Who doesn’t think their calendar or inbox is already too full?

What we actually need is more effective communication.

I’m going to show you how you can spend less than 20 minutes per week to keep your team coordinated and aligned.

First, let’s stipulate a couple of things:

• Electronic delivery is better than a meeting. This gives people a chance to ingest it when they have the time to and you get an archive.
• The update should be digestible by the team in less than 5 minutes. The shorter the better: If it’s too long, nobody’s going to read it. Nobody has ever complained that an email was too short.
• We shouldn’t spend more than 20 minutes putting it together. If it takes you longer than that to produce an update, it’s likely there’s some kind of dysfunction somewhere that’s probably more important to solve than coordination.

Clearly a short weekly update delivered via email is the best possible delivery here. It’s short, so people will read it. It’s weekly, so they’re not going to feel overwhelmed.

Here’s what my weekly update looks like (click for a bigger version):

The weekly update includes only charts and lists. Two of the most scannable elements in all of existence.

You may think that’s a long email, and technically you’d be right. But it’s not that nobody reads emails anymore, they just don’t read crappy ones. This one is always worth their time.

Want some proof? Here’s a designer on my team giving feedback to a group tasked with “improving communication” at our company:

More proof? Here’s a fellow PM committing a crime:

Designers and PMs agree: this weekly update template works.

So, what makes a good weekly update?

• Progress towards goals, including the confidence in hitting those goals. One of the best ways to keep your team aligned and moving in the same direction is to keep your goals top-of-mind. Putting your goals and the progress towards those goals at the very top of every weekly update reiterates what direction you’re moving, and more importantly, why you’re moving in that direction. Adding a confidence indicator of hitting those goals makes it easy to scan, and shows you where you may have opportunities to change course.
• A list of last week’s priorities, and whether or not we accomplished them. A quick “yes” or “no” is all you need. Some teams like to include information about why the task wasn’t accomplished, but I like to err on the side of brevity for readability’s sake. Someone will reply to the email if they really want to know.
• What we should be doing next to make progress towards those goals. This is a list of three or four P1 priorities that your team should accomplish this week to make progress towards your goals.  This list isn’t every single thing your team should do this week, just the P1 priorities. They should be meaty and impact your goals directly: “deploy feature X to 100% of users” is meaty. “Agree on scope for iteration 2 of feature P” is meaty. “Talk to Squad Y about broken feature Z” is not.
• A list of things keeping us from making progress towards those goals. Almost like the standup meeting in Agile, this is where you openly discuss things that are slowing your team down. Don’t call people out here. Being objective in this list makes the medicine go down smoother. For example: “The automation infrastructure makes our test results unreliable, so we need to run them three times before we can accept their results. This adds an hour to the release cycle when there are no failures, and up to a day to the release cycle if there are any.” is way different than “Patrick takes a long time to QA.”. Both tell you the same thing, one gives you something to fix.
• General notes: important stuff that doesn’t fit into one of the sections above. I use this for interesting releases or results, team birthdays, out of office notes and occasionally calling out specific team members for remarkable work.

That’s it. Just 20 minutes of your week will pay back dividends in team alignment. (It took me longer to write this post than it does to write my weekly update.)

Do I have to use email? No. I actually use our wiki and post the link to a couple of channels. If you have an internal wiki, I recommend that you post it there and share the link broadly. This gives everyone on every team a chance to read, comment and respond publicly.

When should I send it out? I do Monday mornings, but I’m starting to think about doing it Friday afternoons instead.

 

How do you know if everyone read it? Believe me when I tell you that it’s obvious when someone hasn’t.

Keeping teams aligned is a big problem in every company ever. Change the way you communicate to (and about) your team with this format and you’ll see the results immediately.

1. Being told the problem and the solution.
2. Changing priorities (or having “multiple priorities”).
3. Not shipping.

We can actually increase team alignment by throwing out most of what we communicate through roadmaps.

In every team I’ve been on, the highest functioning teams have been the teams with the clearest focus and understanding of our goal and our strategy.

And probably just like you, to accomplish that alignment, I’ve always relied on some semblance of a roadmap.

ROADMAP: a list of stuff we wanted to accomplish, and when we would do it.

Let me be embarrassingly honest for a second:

I. LOVE. ROADMAPPING.

It’s really fun to think about everything we should (and could!) be doing to make progress towards our long-term goal. It’s really fun to think about what order they should go in and about how long everything should take.

As I work on my roadmaps, I always imagine people rallying around the “living, breathing document” with crystal-clear purpose and understanding of where we’re going, why we’re going there and when we’ll be able to celebrate our successes. In my mind, they’re pumped, they’re ready to do good work and solve some important problems.

The thing is: nobody reads a roadmap.

• Realistically, you present it to your team and it sparks some conversation, but that’s the last time they look at it.
• Your manager reads it when it’s review time and says it’s great (or to change everything).
• Maybe even a couple of people stumble on it when they’re searching for something else.

But that’s about it. By and large, the roadmap is a doc created for everyone, and ultimately enjoyed by nobody.

We spend too much time creating roadmaps

Roadmaps help communicate vision and strategy. We want to make it obvious to the groups that rely on us that we know where we’re going and how we plan to get there. When I create a roadmap, I think about three specific groups:

1. My team, so they know where to march today and tomorrow.
2. Other related teams (other teams in your group), to communicate what direction your team is marching in, so they know where to intersect or avoid your path.
3. Everyone else (customer service, marketing, etc.), so they can plan for your arrival.

So, we tell each of these groups that we’ve created this grand document for them that will solve all of their problems: the roadmap!

But all of us know the truth:

ACTUAL ROADMAP: a list of things that we plan on delivering over the next year or so that’s immediately out of date as soon as you publish it. Plus, nobody reads it anyways.

However, the problem still exists: how do you keep your team, other teams and everyone else aligned without a roadmap?

Let’s be honest for a second: your team is primarily focused on what’s most important today. We’ve got value to deliver in this sprint or quarter, and a group of really smart developers, designers and QA that are working hard at it. They may be curious what’s coming up later, but by and large, they’re mostly concerned with today.

Outside of your immediate team, most others are less interested in the details than you think. Other teams in your group are interested in what direction you’re headed, but one page on your company’s wiki isn’t the only way they’re going to get that information.

A roadmap has never stopped a meeting from happening, and that’s not going to change today.

Software development teams especially know that development can take longer or shorter than expected because stuff happens: customers hate the first version, dragons are unearthed during development, the group or company strategy changes, or people leave.

And when stuff happens, your roadmap is out of date immediately.

News flash: neither your team, your group, nor any other group expects you to be able to predict the future.

Seriously, how often have you shipped something when your roadmap said you would? Do you know anyone that ever has? Talking to a friend who’s an  “engineering management consultant”, he said that on average, most software projects end up 60% over schedule. Multiply that stat by every project on your roadmap, and even the best project manager would only ship half of what was promised when they promised it.

So:

• Your roadmap is list of features you expect to deliver in the future
• But your team is focused on the present
• Few others care about the details (if they know your roadmap exists in the first place)
• And the dates are more-than-likely wrong

You published a detailed roadmap to create alignment, but it turns out that roadmaps full of features and dates create more work, headaches and misinformation than alignment.

But we can all agree that communicating our vision and strategy to get there is important for the team and for others. How can we do that if we’re killing roadmaps?

Instead of killing roadmaps entirely, let’s make them more useful. Instead of creating a roadmap that looks like a project plan, let’s overly-communicate our vision and strategy.

When starting a project, always do it in this order:

1. Identify the Objective: Define what’s important. Literally write it out. Be as vague as you need to be. “This thing needs to be fast” and “We must get 15% market share” are both completely fine ways of stating what’s important, and will vary depending on the project.
2. Identify the Source: Figure out how to measure those things objectively and accurately. Is it counting logs, counting orders, or receiving a report from a third-party?
3. Set a Baseline: Start measuring and reporting on those things right now. Could be “0” if it’s a brand new initiative, and that’s fine. Just measure it and report on it.
4. NOW talk about how to change those numbers.

It’s completely useless to spend time building something if you can’t, or don’t know how, to measure it’s effectiveness. You’ll end up spending a lot of time over-analyzing “feelings” or over-engineering a solution.

Mostly a reminder to myself.