tagged: velocity

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...

New Year’s Resolutions for ScrumMasters and Product Owners

With the new year, it's time for some resolutions. I've got the same old ones (lose weight, eat better, get more sleep, help more old ladies across the street, stop calling every cat I see "Fajita," and such). But since I fail at those every year, I thought perhaps it would be better for all of us if we made some Scrum-related resolutions. And so here are a couple of…

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:...

Overheard During a Customer Conversation About Estimates

I ended up in a Twitter-storm lately defending the idea that all estimation is not waste. It truly concerns me that more and more agilists seem to be saying this. I will be the first to admit that not every project benefits from estimation. But I suspect that it's a pretty rare project where no estimation at all needs to be done.

Estimating is a way of buying knowledge. If…

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…

Estimating a Full Backlog Based on a Sample of It

I want to address a question I was sent recently and that I get asked about once a month. The question has to do with how we estimate how many hours it will take to deliver a given product backlog if we have no historical data at all. My first bit of advice is always to try to put off answering until you're able to get even one sprint of historical data. But that's not always…

Estimating Non-Functional Requirements

A few weeks back I promised someone I would blog about the unique challenges of estimating non-functional requirements. First, let's remember that a non-functional requirement is a requirement that is more about the state of being of the system than about one specific thing the system does. Non-functional requirements often have to do with performance, correctness,…

Sliding Toward Success

You may have noticed we’ve been adding agile project management tools to the Mountain Goat Software website occasionally. We have a tool for calculating a confidence interval around your velocity data as well as various tools for prioritizing user stories or projects against one another. I’ve got a new tool to announce today—Project Success Sliders. Project Success Sliders…

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 they…

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 points…

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 the…

Improving On Traditional Release Burndown Charts

I want to use this month's blog posting to introduce a type of burndown (and burnup) chart that I find useful. I've been drawing this style of burndown chart for years and have coached many of my clients to do the same. Unfortunately, we've had to draw it either by hand or in tools like Visio and OmniGraffle because the agile tool vendors haven't (to my knowledge) hit on this…

Working with “Storyless Tasks”

A question I get frequently is what to do with tasks that do not belong to a particular user story or product backlog item. Common examples I’m asked about include tasks like “update the build server to use the latest version of FitNesse.” Fixing bugs from prior iterations are another common example. I’ve sometimes heard of these tasks that don't belong to a particular product…

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.

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.

Instant Access

Sign up to get Mike’s blog posts delivered right to your inbox as they publish.