What Are Story Points?

Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work.

When we estimate with story points, we assign a point value to each item. The raw values we assign are unimportant. What matters are the relative values. A story that is assigned a 2 should be twice as much as a story that is assigned a 1. It should also be two-thirds of a story that is estimated as 3 story points.

The Dangers of a Definition of Ready

Although not as popular as a Definition of Done, some Scrum teams use a Definition of Ready to control what product backlog items can enter an iteration.

You can think of a Definition of Ready as a big, burly bouncer standing at the door of the iteration. Just as a bouncer at a nightclub only lets certain people in—the young, the hip, the stylishly dressed—our Definition-of-Ready bouncer only allows certain user stories to enter the iteration.

Incentives and Deterrents for Starting Daily Scrums On Time

I recently emailed everyone who subscribes to my weekly tips a list of suggestions for ways to motivate team members to arrive on time to the daily scrum. For example, many teams have a rule that if you arrive late, you put a dollar in a jar as punishment for being late. Ideally the collected money is donated to a charity at the end of a project or after it reaches a certain amount.

How to Prevent Estimate Inflation

I spoke with a Scrum Master recently who told me his team had nearly doubled their velocity in only two months. Rather than be happy about this, though, he was concerned.

He knew the team had not suddenly become twice as productive. In fact, he doubted they'd actually sped up at all. Yet their velocity showed they had.

Sprint Planning for Agile Teams That Have Lots of Interruptions

Many teams have at least a moderate ability to plan and control their time. They're able to say, "We will work on these things over the coming sprint," and have a somewhat reasonable expectation of that being the case.

And that's the type of team we encounter in much of the Scrum literature--the literature that says to plan a sprint and keep change out.

But what should teams do when change cannot be kept out of a sprint?

In this post, I want to address this topic for two different types of teams:

  • A team that has occasional, but not excessive, interruptions
  • A team that is highly interrupt-driven