Articles and Posts 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…

Don’t Take Partial Credit for Semi-Finished Stories

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

Coming close only counts in horseshoes and hand grenades.

That pretty much sums up my view on whether teams should take partial credit on nearly finished

How to Estimate Velocity As an Agile Consultant

Many of you work in a dedicated in-house team, but some of you contract with companies for Scrum and agile consulting. One problem that sometimes arises as an agile contractor is when the prospective client wants an upfront commitment on the scope of the project, but the Scrum consultant feels...

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

Mike Cohn Speaking at Agile 2013 in Nashville, TN

I'm going to be speaking at Agile 2013 in Nashville this summer. My 75-minute session will be part of an Agile Boot Camp track that is targeted mostly at people new to agile to help them understand the basic concepts, terminology, methodologies, and practices of agile development. My session will be

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…

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

5 Free Agile & Scrum Tools for Project Planning and Prioritizing

Mountain Goat Software and Mike Cohn, author and Agile Scrum expert, have announced the release of four free tools used in agile and scrum projects for planning and prioritizing.

Layfayette, CO November 6, 2010 -- Mountain Goat Software, an agile training and scrum certification company, has released five free agile and scrum tools ScrumMasters and Agile teams can use…

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…

Estimating Work Shared Between Two Backlog Items

Product backlog items can be ideally written to be independent. It is the hallmark of a good team that its members can implement product backlog items in any order. However, it would be nearly impossible to remove all dependencies between product backlog items and so our goal becomes minimizing important dependencies rather than eliminating them altogether. But any…

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…

Announcing the Tools Section of Our Website

A nice side effect of having the Succeeding with Agile book done and in print is that some of my time has freed up for other projects. One such project has been the creation of some free agile project management tools that we're making available on the Mountain Goat Software website. I've wanted to make some of these available for a long time so it's nice to finally be able…

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…

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…

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…

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

Sprint and release planning should be in different units

A common source of confusion on agile teams occurs when the sprint ("iteration") backlog and the product backlog are both estimated in hours. To avoid this confusion I strongly recommend estimating these backlogs in different units. In sprint planning the team should always talk of tasks and hours. Sprint planning covers the horizon of typically two to four weeks out. In…

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.