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…

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…

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…

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.