Now vs. Not-Now Prioritization Along with Medium-Term Goals

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.

In last month’s newsletter I wrote about how we make personal financial decisions in a now vs. not-now manner. We don’t map out must-haves,...

2 Times to Play Planning Poker and 1 Time Not To

This post continues my recent series about Planning Poker by focusing on when to estimate.

Because Planning Poker is a consensus-based estimating approach, it is most appropriate to use it on items that require consensus. That is, I recommend using Planning Poker on product backlog...

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…

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…

When You Miss the Point of Sprint Planning Meetings

In a recent interview for an upcoming agile book by Sondra Ashmore and Kristin Runyan, they asked me questions regarding several areas of agile development and Scrum. In the last two posts, I explored questions about the product backlog and estimating. This time, I’d like...

Number, Name, Date-Stamp or Sing Your Sprints

Some teams like to number their sprints. Most simply use integers: Sprint 1, Sprint 2, Sprint 3... But I've also seen teams use things like Sprint 1.1 and 1.2 to indicate the first and second sprints of the first release of a product. The second release would start over with Sprint 2.1.

I've also seen teams date-stamp their sprints. A sprint ending on 18 May would be known…

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…

Agile Teams and Risk Management

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.

Ahh, it's fall. Not only does it bring the return of great, cooler weather but it also brings [American] football. And when there are football games, there are articles about football…

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…

Estimating and Planning Are Necessary for Maximizing Delivered Value

Because I'm so interested in estimating and planning, I always take notice when I see a new blog post or news group posting claiming, "Estimating is waste! Don't do it!" The thing that never shocks me about these arguments against estimating and planning is that they never come from the business people for whom we are developing products or systems. They understand the value…

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…

Managing Risk on Agile Projects with the Risk Burndown Chart

Risk management is a central part of traditional project management and is included as one of the knowledge areas in the Project Management Institute’s (PMI) body of knowledge. In many of my classes, participants ask how Scrum and agile address risk management. Some are concerned that agile or Scrum ignore risk management completely. Let’s see why this is the case. First, a…

Comparative Agility Assessment - Determining How Agile You Are Comparatively

With this in mind, Kenny Rubin, Laurie Williams and I created the Comparative Agility assessment (CA), which is available for free online. Like the Shodan Adherence Survey and Agile:EF, a CA assessment can be based on individual responses to survey questions. However, it was also designed to be completed by an experienced ScrumMaster, coach, or consultant on behalf of a team or company based on interviews or observation.

Mix the Sizes of the Product Backlog Items You Commit To

Teams used to a sequential development process have become accustomed to hand-offs between specialists. Analysts hand their work to designers who hand it to programmers who pass it on to testers. Each of these hand-offs includes some overhead in the form of meetings, documents to read and perhaps sign, and so on.

In part because of this overhead, the hand-offs tend to be…

Synchronize Rather Than Overlap Sprints

Today I want to discuss synchronized iterations and why they work best on multi-team projects. Managing dependencies among multiple teams is a difficult agile project management challenge. On my first Scrum project, we started with only one team. That project soon grew to three teams, with the typical dependencies between them. I quickly arrived at what I thought would be a…

Clarifying the Purpose of Iteration Planning

I was recently asked whether it would be OK for a team to complete their iteration planning without going to the point of estimating tasks in hours. To answer this, let's consider what the purpose of iteration planning is. In my view, the purpose of the iteration planning is for the team to arrive at a commitment to some set of functionality that they feel reasonably…

Prioritizing Tasks Within a Sprint

In the discussion that ensued from another post here, Brian Bailey asked a great set of questions. The questions were big enough that I've moved them here. I'm going to intersperse Brian's questions and comments with my responses. Brian started with:

If the product owner is onsite and part of the same company, what role should she have in prioritizing tasks within a…

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…

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

Differences Between Scrum and Extreme Programming

Scrum and Extreme Programming (XP) are definitely very aligned. In fact, if you walked in on a team doing one of these processes you might have hard time quickly deciding whether you had walked in on a Scrum team or an XP team. The differences are often quite subtle, but they are important. I think there are four main differences between Scrum and XP:

  1. Scrum teams…

The Critical Path on Agile Projects

On traditional, sequential process an important part of the project manager's job is identifying the project's critical path. The critical path is the sequence of activities that will take the longest to complete and that, therefore, determines the overall length of the project. For example, suppose that my wife and I want to see a movie this afternoon. Before we can go to…

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…

Writing Contracts for Agile Development

User stories are a great way to get people talking about requirements. However, there's a reason why we invented the written word: to make sure that nothing we've said is forgotten or misunderstood. This article explains why contracts are a good way to capture not only the user stories themselves but also to spell out what constitutes the successful implementation of each story.

The Certainty of Uncertainty

If the only certain things in life are death and taxes, why do so many teams think that if they plan well enough they're somehow going to add software to that short list? This article deals with the mistakes team make when they try to account for every potential need and how best to plan for those things that users don't even know they want (or don't want).

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.

A Regular Heartbeat

We all crave regularity. We want a steady rhythm and a strong downbeat so we know the steps we need to take. This article explains how to give that sense of continuity to your software teams through fixed-length iterations, whatever length that is.