# On the benefits of pitches

Ever start a sprint with a story that, even though it's been refined, still leaves a lot of questions that have to be figured out in the sprint? It may not even be apparent where the boundaries of the related epic are. It's a tough nut to crack because stories may seem simple until you actually get to work on it. And as the complexities unfold, a lot of it might need deciding 'on the spot' under the strain of time pressure.

I find it interesting to see how teams across companies handle these types of situations. Some stop the task and return it to refinement, others simply choose the best option that leads to a releasable product at the end of the sprint. Personally, I'm a proponent of the way Basecamp handles this. Before handing their equivalent of an epic to a team, they shape it. The outcome of that process is a pitch - a high level description of the use case, budget, proposed solution and go/no-go areas.

# Elements of a pitch

• Problem that you're trying to solve
• Appetite (how much time are you willing to spend on this)
• Solution (rough explanation of the way you want to resolve the problem)
• Rabbit holes (details about the solution worth calling out to avoid problems)
• No-go (what you won't do within the scope of the pitch)

Here's why pitches help both the project team and the project owner:

# Solving high-level problems upfront

All too often discussions get stuck in implementation details, not allowing the team to talk about the parts that actually ‘move the needle.’ A pitch forces you to come up with the overall solution before you drill down into specifics.

# Preventing the sunk cost fallacy

By default, the appetite does not get an extension. The work needs to be hammered down enough upfront so it's feasible to build. If not, the pitch wasn't lean enough and needs to go back to the drawing board. This limits the risk of continuing to pursue dead ends just because you started the work on it. Think of that as a failsafe.

# Constraining the depth of the rabbit hole

Programmers love puzzles. It's therefore no surprise their solutions often include safeguards for usecases the business hasn't even though of that. To an extend, that's a good thing. It goes awry when that attitude blocks you from shipping something better than there is now, which should generally be the goal of any project.

Pitches protect you from this by defining the boundaries upfront.

# Short and productive

Pitches are concisely written, contain all relevant context and can be read up-front. Very little design polishing goes into it, it's all about conveying ideas. Perfect for stakeholdermanagement. As a result, many pitches can be discussed in an hour which is a great thing when working with clients across time zones.