Small team planning

Introduction

I’ve worked at 5-10 different organizations, most of them were startups or startuppy companies. I’ve done a lot of planning in small teams, and also taken part in company-wide leadership planning. Here I will describe what has worked well for me in small team settings, focusing on time estimation.

Team activity

Team planning typically occurs at the beginning of each quarter or half. It is an activity for whole team; everybody needs to own the plan. The techlead or engineering manager cannot do it alone, because there are multiple steps where everybody’s input is needed to generate project ideas and estimates.

Planning vs goaling

The focus here is on planning. Planning is not the same as goaling.

    Goal = what we want to do

    Plan = what we can do

A plan incorporates resource and dependency contraints: people, time, money, team structure, software architecture, etc. Another way of saying this:

    Goal = where we want to get

    Plan = how we get there

When goaling, if you don’t take into account resource and dependency contraints (=what makes a good plan), the goals will be unrealistic. When planning, if you don’t have a goaling direction, you won’t work toward the right direction. Planning and goaling go hand in hand, it’s a back-and-forth.

In my experience, a lot of people are bad at planning, and tend to overpromise and underdeliver. I prefer to underpromise and overdeliver.

When I was a young Techlead , the first time I did small team planning, we spent hours writing lots of sticky notes, estimating mandays, we channeled Fred Brooks. At the end, when we were finished, we leaned back and looked at our plan, and I laughed out. I said: “Somehow we managed to fit all projects we can think of into the quarter! We’ll be laid off because there will be nothing left to do.” It was a joke. We overpromised and underdelivered, because we didn’t know how to make a good plan.*

Counting days

The basic process is straightforward:

1. Draw a calendar on the whiteboard. Columns are people, rows are weeks in the quarter / half that you’re planning for. If you want, make cells for days, but I usually don’t. The point of the exercise is to count how many weeks we will have to work on “new stuff”.
2. Count how many weeks are in the quarter, and make a row for each week. Number the week as the week-of-year, eg. W44.
3. Cross out any weeks that are in the past.
4. If you’re doing this exercise in the middle of the week, cross out the current week.
5. Cross out bank holidays.
6. Cross out days for team offsites, hackathons, etc.
7. All team members cross out weeks in their column when they will be on vacation. If you’re unsure which week it is, take a guess.
8. Mark 1-2 day per week for interrupts. In my line of work, for a generalist data team, there are lots of interrupts (same goes for many software engineering teams). In my experience, 20-30% of time should be assumed to be interrupts (infrastructure breaks, logs change, new data breaks a pipe, dashboards break, ML model regresses, questions from PMs, SWEs, designers, AMs, sales, marketing, finance...)
9. Estimate meeting load. Everybody open their calendar, and look at the last 2 weeks to estimate meeting load. Imagine compressing your meeting load into full days, and cross out that many days. Note: meetings are not interrupts here.
10. The Techlead for a 4+ person team will spend 50%+ of their time on management duties. Take that time off from that person’s column.

At this point, there is a per-person budget left. This is how much time is available to work on new stuff, to have direct impact.

This is what an in progress planning table might look like:

Direct vs indirect impact

Sometimes people get upset because it seems too little time is left for new stuff. You could argue that putting aside days for interrupts and meetings is "planning to underperform". I would not agree with that, it's just a realistic plan.

On the one hand, yes, we all are spending a lot of time in meetings, and some of the meetings are useless; but that has nothing to do with planning. Planning may draw attention to it, but it’s not a planning issue. To decrease interrupts, have your team set up the interrupt magnet system (=an assigned team member who handles interrupts that day/week, same idea for infra magnets). If you manage to push down interrupts and meeting time, great, you'll have more time and will end up underpromising and underdelivering, and on the next cycle you can adjust down your interrupt/meeting estimate.

On the other hand, and this is the point: a lot of impact is delivered indirectly. It may be realized by another team, or later. Spending time talking to people or fixing stuff is not underperforming. A great example is a hackathon: at Facebook, a lot of important features were first built at hackathon, even though, in terms of planning, a hackathon would be “crossed-off time”. Hackathon also have a lot of other positive effects.

Project list

As a team, write a list of projects the team would like to work on, taking into account existing goals. Have everybody write their ideas on a sticky note (before the meeting), and then collate the ideas together on the whiteboard. The goal is to make sure everybody can give their ideas without being over-talked in a meeting setting.

The next step is to decide how much work to allocate to each project, who works on each. I will skip the “who” and figuring out dependencies here.

Planning poker

The point of planning poker is to make sure everybody who is involved in a project can give their manday estimate, without being influenced without others who speak before. The easiest way to do it is to have people write their estimate on a sticky note, and then share it. Super-high and super-low estimates should be explained. The goal is to arrive at a realistic estimate. “Realistic” is not the same as “consensus”, eg. you should not take an average or median of estimates. People who are better at planning (=usually more senior people) need to have more weight, while people who are gaining experience should use this experience to learn how to do a better job estimasting.

Mandays

Be careful about mandays versus calendar days when estimating projects: Pure mandays is how much time you’d spend on something if you were to work uninterrupted. Real mandays is how much time you will spend on it in real life, since you’re less efficient because of interrupts (but not counting time spent in interrupts and meetings). Calendar days (calendar weeks) is how much time will elapse between start and end, also counting interrupt time and meetings, weekends. For example if your compressed meeting load is 1 day per week, 1 day per week is interrupts, and a task is estimated to take 4-5 pure mandays, then probably it will take 6 mandays, and overall it will consume 2 calendar weeks (1+1+3+weekend+1+1+3+weekend).

Different people think in different quantities when planning (pure mandays, real mandays, calendar days). Make sure you’re talking about the same thing.

Coarse-graining

I prefer to keep the plan coarse-grained, and think of bigger projects/tasks, that are at least 1-2 weeks in size. I think trying to think ahead in smaller granularities is unrealistic. Good and motivated people will be able to manage the sub-tasks within coarse-grained projects during the quarter on their own (juniors with regular help).

Timing

At this point we know how much time each person has available, projects, and who works on what projects, so we can put it into the table, taking into account dependencies. This gives our estimated completion times. In my experience, for software, at best month-grained can be taken seriously (“We will start working on this in Nov, we will ship sometime in Dec”), but often only quarter-granularity is dependable ("We will ship in Q4").

Projects and goals

Planning and goaling is a back-and-forth. If the plans and goals are too far off, one or both has to be adjusted; maybe the goal was too aggressive and needs to come down, or the team needs to find additional time this quarter and aggressively say no to interrupts and cancel meetings, or both.

Jiggle

I like to give space/time to reflect and adjust. After the initial meeting, we take a few days to think about it, and schedule a second, finalizing meeting, where we have an opportunity to make adjustments, add in stuff we missed.

Meeting minutes

The techlead or manager should take a picture of the table, enter it into a spreadsheet, and share it with the team. Then, if the team also uses software such as Trello or Jira, enter it there.