Know Exactly What Velocity Means to Your Scrum Team

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

To see how this applies to an agile project, consider the issue of whether a team should earn velocity credit for fixing bugs during a sprint. A team that uses velocity to measure how much functionality is delivered in a sprint will not claim credit for bug fixes. No new functionality...

How Can We Get the Best Estimates of Story Size?

I was recently interviewed for an upcoming agile textbook written by Sondra Ashmore and Kristin Runyan. They asked me questions regarding several areas of agile development and Scrum. Last week, I explored questions they had about the product backlog. This week, I'd like to tell you about the conversation we had about estimating.

The conversation began as follows:...

Simulating a Project by Resampling Velocity

I normally write about a new agile project management technique only after I’ve used it for a couple of years and found it successful in a couple of different contexts. In this post I want to share such a technique. It’s a statistical technique called “resampling” that I’ve become quite fond of for making predictions about future velocity, a method for measuring the rate at…

Should Story Points Be Assigned to a Bug Fixing Story?

Sometimes teams write a user story for this activity such as: "As a user, I want at least 15 bugs fixed" or, "As a user, I want you to spend about 50 hours this sprint fixing bugs so that the application becomes gradually more high quality." Even a team that doesn't explicitly write such a user story will usually include a row on its taskboard to make the agile defects and…

Why There Should Not Be a “Release Backlog”

I haven't heard the term "release backlog" in many months, but it's come up in three conversations over the past week. So, I want to share my thoughts on whether a team using an Agile project management approach should have a backlog known as a release in addition to the conventional Product and Sprint (or Iteration) Backlogs.

First, let's clarify what people mean when…

Predicting Velocity When Teams Change Frequently

As a measure of the amount of work completed in an iteration, velocity works extremely well when teams are relatively stable. If the same people stay on a team, it is reasonable to assume that the amount of work they complete will be relatively constant from iteration to iteration. This allows us to plan using inferences such as "This team has an average velocity of 25…

Is It a Good Idea to Establish a Common Baseline for Story Points?

In a previous post, I wrote about how to establish a common baseline for story points across relatively large teams (a few hundred developers). In this post I want to consider whether doing so is a good idea. The need for a common baseline to story points usually arises from the reasonable desire to know how big the entire project is. To know that, we must know the size of…

Establishing a Common Baseline for Story Points

A common criticism of story points is that the meaning of a story point will differ among teams. In this post I want to describe how can we establish a common definition of a story point across multiple teams within an organization.

The best way I've found to do this is to bring a broad group of individuals representing various teams together and have them estimate a dozen…

The Chivalrous Team Member

In seeking to improve how we develop software, we continually inspect and adapt. While thinking recently about the characteristics of the ideal team member, we found similarities between the best-performing soft- ware teams of today and the Knights of the Round Table. This article considers the Code of Chivalry as applied to team members.

Why I Don’t Use Story Points for Sprint Planning

As described in Agile Estimating and Planning, I'm a huge fan of using story points for estimating the product backlog. However, I also recommend estimating the sprint backlog in hours rather than in points. Why this seeming contradiction? I've previously blogged on the reasons why I recommend using different estimation units (points and hours) for the different backlogs.…

Estimating With Use Case Points

Too much work goes into use cases to not employ them to their full potential. By assigning points to use cases you can reliably measure the size of an application and derive an estimated duration for a project. Read this article to find out more.