tagged: story-points

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.

Assigning Story Points at the Right Time—Or Not at All

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.

As much as I value estimating the product backlog, not every team needs to do it. And those who do estimate the items on their product backlog need to understand why they do it, not just how to do it. There are two reasons to estimate...

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…

Release Planning: Retiring the Term but not the Technique

I want to address a term in the Scrum (and even the broader agile world) that has largely outlived its usefulness: release planning. As commonly used (including by me), "release planning" has meant looking forward a handful (or more) sprints and making a prediction of what would be delivered by then. Ideally these predictions were expressed as ranges, perhaps even using…

Points Are About Relative Effort Not Ranking

I'm thinking of buying a new car. So I've put together a list of cars to consider. Here they are in priority order:

  • Bugatti Veyron Super Sports
  • Pagani Zonda Clinque Roadster
  • Lamborghini Reventon
  • McLaren F1
  • Koenigsegg CCX
  • Porsche Carrera GT
  • Aston Martin Vanquish
  • Toyota Prius
  • Toyota Camry
  • Tata Nano

Unfortunately, though, I'm not sure I can afford my top priority…

Recommendations, Not Rules

I seem to be encountering more and more people who want to codify agile into a set of rules. I've seen this lately in authors of books, blogs or PDFs about agile or Scrum that say "You must do this" or "If you don't do this or all of that then you're not doing it right." Over the last few months I also encountered this in conversations with a few Project Management Offices…

In Defense of Large Numbers

People are often surprised that I allow (or even encourage) people to estimate with story points as large as 20, 40, and 100. We include these values in the decks of Planning Poker cards that we sell and give away in classes and at conferences. Yet many people tell me they start out my taking the 20, 40 and 100 cards out of the deck and throwing them away. I find this…

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

The Problems with Estimating Business Value

I occasionally see teams that want to put an estimate of "business value" on each user story. They usually do this for either or both of two reasons:

  1. to be able to measure the amount of "business value" delivered to the organization, usually graphing this sprint by sprint
  2. to be able to prioritize user stories by comparing the business value of each story to its cost

It’s Effort, Not Complexity

A client asked me, "When will my team be done with this project?" This is probably the bazillionth time I've been asked that agile project management question in one way or another. I have never once been asked, "How hard will my team have to think to develop this project?" Clients, bosses, customers and stakeholders care about how long a project will take. They don't care about how hard we have to think to deliver the project, except to the extent that the need to think hard implies schedule or cost risk.

Velocity as graphed over the last nine sprints.

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…

Velocities before teams told they would be compared

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…

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

treemap of two floors of a house

Visualizing a Large Product Backlog With a Treemap

In the early days we promoted agile project management only for small teams because that was where it originated. We had plenty of experience to say that agile worked well on seven- to 10-person teams. We were also quick to learn the techniques that allowed agile project management methodologies to scale up to around 20 to 40 people. These days, though, there are many truly…

A traditional release burndown chart

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…

A generic task board

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…

When Should We Estimate the Product Backlog

I was recently emailed a question asking whether the sprint planning meeting should start with time allocated for putting story point estimates on any user stories that have not yet been estimated. No, I don't think this is a good idea. Keep in mind that we put estimates on product backlog items (which I recommend be user stories) so that:

  • the product backlog can be…

Should Companies Measure Productivity in Story Points / Ideal Days?

Using story points or ideal days to measure productivity is a bad idea because it will lead the team to gradually inflate the meaning of a point--when trying to decide between calling something “two points” or “three points” it is clear they will round up if they are being evaluated on productivity as measured by the number of story points (or ideal days) finished per…

To Re-estimate or not; that is the question

Should a team that is estimating in story points ever re-estimate? This is a question I'm commonly asked and would like to address here. Most people have a natural feeling that re-estimating is somehow wrong but they can't quite say why. I'll encourage those individuals to stick to their hunches, and hopefully I can provide of the reasoning that supports your natural…

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…

Distance Remaining Is More Important than Distance Covered

With no land in sight to guide them, it would have been all too easy for early sailors to get lost in a seemingly endless sea. All too often, software projects also lose sight of when and if they'll reach their destination. This article explores what ancient mariners knew about navigation that we can apply to charting software project progress.