Chase Seibert

Director of Engineering at Dropbox

How do you make sure that your team is not signing up for too much?

There is no substitute for a well functioning team that has built trust over time. When the product owner and the technical lead have been through war together, they can right size almost any project and prioritize it correctly. On new teams, how much work to sign up for can be a source of conflict. In that case, it’s the technical lead’s job to make sure the work load is realistic.

If you’re having a planning conversation with the product owner, how should you think about turning a “No, we can’t do this” to a “Yes, and this is what we can deliver and when”?

Break into Milestones

Working sustainably is more about how much scope you are delivering per unit of time than it is about which things you are doing. Something that is 1,000 total man hours of work is fine if you’re only delivering the 20 hour version this sprint.

Pick a work item and break it down into pieces. Can you simplify one of the pieces? Can you postpone one of them? Can you agree to hack a solution for one piece for the MVP and fill it in afterwards? Is one requirement accounting for a disproportiuanate amount of the effort? Propose dropping it and see what people say.

Set milestones up front. See how quickly you can get to a working version. An early milestone does not have to satisfy all the criteria. But it has to be working and shippable. If the team’s priorities shift, you can have a discussion about whether the last milestone is a good place to leave the project for a while.

Back to Scrum Basics

There is a reason why Agile principles are so widespread. They work.

  • Stack rank the work items. Focus your energy on trying to cut items that are the lowest priority for the product owner.
  • Have a stable velocity. If your team has been running for a while, you hopefully have predictable velocity and accurate estimates. In that case, it’s simple math as to how many stories you can do. Remember, you can estimate epics, too.
  • Break stories into smaller pieces. If you can show that one piece accounts for a lot of the work, maybe you can agree to do that work later.
  • Agree to commit to less, but pull in additional stories if there is more time. Again, textbook Agile.

For all these items, the Scrum Master is responsible for making sure the team is living up to their own process. They should be the one to say whether the team can commit to more work on not. This is one good reason for the Scrum Master to NOT be one of the engineers on the team (or the product owner). There is a perceived conflict of interest.

Tie Breakers

If you still cannot decide between a too long list of work items, you might need to invoke these roadmap planning judo moves.

Note: no actual product owners were harmed in the making of this list.

The Outside the Box

Deprioritize work if there are significant issues with the design. If there is similarly high priority work that has more solid design, it may make sense to give this item more time to bake.

The Big Picture

Deprioritize work if there are better technical solutions that the team can pursue when they have more capacity in the future.

The Deflection

Deprioritize work if there is another group that makes more sense to work on this item.

The Disappearing Engineer

Deprioritize work if not every person-day of engineering you’re assuming actually exists. Does someone have a vacation coming up? Is there a project that you might need to pull people off for? Are you accounting for interrupt driven work?

The Consolidator

Deprioritize work if you have more work items than engineers. Consider having an engineer focus on one task at a time. In many cases it would be better to go deeper on high priority items in the backlog versus doing more discrete items.

Deprioritize work if there a dependency which is not already in production and battle tested. It’s risky to assume that two interdependent work items will both land simultaneously.