The Pitch 28 February, 2017

The Pitch

Most people think of a pitch as a rehearsed reason someone gives when they need help making a new idea come to life. I think it should be recognized more widely as a good way to communicate in business. People should be pitching much more often than they are.

Here are a few situations that I think it applies to.

  • Hackathons
  • Raise Meetings
  • Feature Requests
  • One-on-One Meetings
  • Team Meetings
  • Planning
  • Anything you're working on - What if someone comes up to you and says "That looks interesting. How will it actually help us?"

Here is a simple way to organize a pitch. Be able to explain the following.

  • A problem that exists
  • Why the problem matters to the listener
  • How you're trying to solve it
  • Why your idea matters to the listener

Give it a shot.

Sprint Length Heuristics 31 January, 2017

If you're thinking of changing your sprint length, but aren't sure if you should run shorter or longer sprints, here are some heuristics that I've observed. First, I'll give you some background on what I've tried.

At a previous startup, we had 1 week sprints. That worked fine at a startup because everyone did everything. Devs were devs, but they were also client services, designers, DBAs, and devOps. Later, while working at a more established company, we ran three week sprints because there wasn't a pressing reason to change. Let me rephrase that last comment. The established company was used to running sprints like every other established company and 'best practice' was equivalent to whatever was in standard training materials. Now, after switching from a Kanban style (for reasons I won't discuss here,) I am back to 1 week sprints. I feel like that's currently the best match for the company I'm at.

I understand that there are trade-offs in the sprint length that is chosen. So I'll get on with the actual heuristics I'm using to set my sprint lengths.


<------------------------------------------------>
SHORTER                                             LONGER
smaller feedback loop                       You know your strategy
Forces you to break up issues          Priority of features doesn't change often
You may be reactive                          You're just starting out and going with historical opinion


I hope you can use this scale to better match up your circumstances to an appropriate sprint length for your company.