Estimation causes waste, slack creates value

• Manager’s measurement #1: count how many people talk in every 4 minute cycle. If it drops below 50% of the team, people are preaching, not communicating. Take it offline.
• Manager’s measurement #2: Can the team identify the top one or two questions about the feature? That is, do they know what they need to learn about the story card, be it clarifying user needs or technical risks? If so, let them start working on it. Oh, and at this point, it’s OK to ask how long they think it will take to answer the question.
• Manager’s measurement #3: If the estimate for answering the next question is greater than 2 days, reduce scope and re-prioritize. We need to make sure the Product Owner is learning about the business needs and code just about as fast as the developers.
• Manager’s measurement #4: How many days has it been since a paying customer gave you feedback on your active development? I’ve had teams that averaged around 2 days… my current team is much worse, probably averaging around 15 business days–but there may also be legitimate differences for different business models.
• Manager’s measurement #5: By week 2 have you deployed something for your top two release priorities? By week 8 of this release, have you deployed a subset of all key features for this release to paying customers?
• Manager’s measurement #6: How many hours of creative slack did your team do this week?

Estimation causes waste, slack creates value (http://www.management30.com/posts/2010/5/9/estimation-causes-waste-slack-creates-value.html) - Page is not avaialble