Articles and Posts Tagged “story-points”

Announcing FrontRowAgile.com for Video Training

I’m happy to announce the release of a new website, FrontRowAgile.com. FrontRowAgile.com will provide the highest quality video training on agile and Scrum.

The site launches with two courses from me and with courses from others soon to follow. In addition to hosting all my current and upcoming video courses, FrontRowAgile.com will soon feature:

  • Ken Rubin on Agile…

3 Roles That Need to be Involved in Agile Estimating with Planning Poker

When estimating your product backlog with Planning Poker, it’s important to have the right people participate. Let’s go over who needs to be there, and what the job of each is during an agile estimating meeting. First, of course, we start with the team. All of a Scrum team’s...

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

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

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

Learn Agile Estimating Online with Mike Cohn for Half Price

We’ve decided to run a spring sale of our popular eLearning course: Agile Estimating and Planning. Until May 19, you can access the entire course , worth 4PDUs, for half off. Some of the things we cover include:

  • The problem and the goal.
  • Story points and ideal days.
  • Estimating the product backlog.
  • Release planning.
  • Multi-team projects.

Here’s a sneak…

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…

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

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…

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…

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…

How Do Story Points Relate to Hours?

I'm often asked about the relationship between story points and hours. People who ask are usually looking for me to say something like "one story point = 8.3 hours." Well, that just isn't the case (especially since I made up 8.3 hours). Let's see what the real relationship is between the agile point system vs. hours system. Suppose for some reason you have tracked how long…

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…

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…

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…

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…

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

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.

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.