I buy new cars infrequently, typically every 10 to 12 years. So when I bought a new car in 2003 I was surprised at the many advances in technology since I’d purchased my previous car, a 1993 Honda. One advance I was particularly pleased with was a sensor that automatically detects low air pressure in my tires. It is sometimes hard to tell by looking at a tire if its pressure is low, and checking tires manually is a dirty job, so I did it infrequently. A continuous test of tire pressure was, I thought, a tremendous invention.

Most sprint planning meetings I have attended were fun. The ones that weren’t involved a poorly groomed product backlog, whose high-priority items were not workable, not ready to be pulled into the sprint. When the backlog hasn’t been prepared prior to the meeting, the product owner and team often carry out impromptu grooming activities. These consume valuable planning time and usually result in poor requirements and weak commitments. Plus, everyone is fed up and exhausted by the end of the meeting. As a consequence, the product backlog items that are likely to be worked on in the next sprint have to be prepared prior to each sprint planning meeting. Although it is the product owner’s job to make sure that the work gets done, preparing the product backlog should be teamwork involving the product owner, ScrumMaster and team. We begin the preparation work by choosing a sprint goal.

I've heard people criticize agile methods as being too reactive and focusing too much on the little picture and ignoring larger goals. This is a misunderstanding of a basic idea of agile. Agile methods are't about thinking small and taking small steps towards a goal, applying programming an management discipline along the way.

Planning aoker, an estimating method popular with tgile teams can address some of these issues. Briefly, planning poker involves getting the developers on a team together to estimate stories using a deck of cards that have numbers that represent units of work.