Stop committing to iteration scope!

This may seem like heresy in the world of "Scrum requires commitments from the team", but think about it.

If your iteration is about two weeks (give or take) and your team is pretty much fixed for that period of time (you can't really "change" a team that fast), then what else is left? Yes, precisely: only scope if left.

In a typical iteration your time is fixed (it better be if you are doing Scrum), your capacity/team is fixed so you are left with only one decision to make: choose to respect either scope or Definition of Done.

Definition of Done is probably the single most important practice as it is the practice that makes sure you have a future, so your choice should be pretty obvious! Don't commit to scope!

It's not that simple, mister!

Of course, the devil is in the details. How can you commit to "anything" for an iteration? Here in lies the crucial point of this post: User Stories are not fixed scope! If you have read anything about User Stories you know of the INVEST properties that each story should respect. The second property is N-Negotiable. This means that even if you commit to deliver the value explicit in the User Story the actual way you deliver that value is to be negotiated with the Product Owner/Customer. This negotiation is the key dynamic for teams that want to succeed at meeting their iteration commitments.

In an iteration you will discuss which are the key User Stories to be delivered. However, later on, when you find out that you are over-budget you should take clear actions, together with the Product Owner, to find out what is the key functionality for each of the remaining stories that should be delivered within the ongoing iteration. And drop the rest!

There's no point in doing over-time and delivering something you will have to throw away later on (because of quality problems or other). Sit down with the product owner and decide what to drop, what to keep in order to deliver the maximum amount of customer value without breaking the most important commitments Schedule and Quality.

Keep your relationship with the product owner as that is the most important relationship for an Agile team.

Photo credit: d_oracle @ Flickr

What is Velocity? (in agile software development)

Velocity is a term used in agile software development to illustrate the "rate of progress" for a team or a set of teams (i.e. a project/program).

The simplest way to define velocity is: the number or user stories a team/project can do in one sprint ("do" here means that it really is done and potentially ready to ship).

Without the use of velocity you would not be able to draw your teams's burndown, as velocity is the slope of the burndown curve, i.e. how fast are you burning down the stories (or story points or hours) that you committed to for the ongoing sprint.
At a project/progam level, velocity is the rate at which the whole project is burning the User Stories (or requirements) from the backlog.

Also, without knowing your team/project's velocity you can not make longer term planning (over 1 sprint) or even release planning. Hence the importance of knowing your velocity!

In the first 1 or 2 sprints that you run, you will have to estimate your team/project's velocity as you don't have enough data to project your past performance into the future. However, after 3-4 sprints you should start using an average of your past velocity to plan the future and update the release plan.

Note that velocity is a range, not an exact number. For example, if you have developed 2, 5 and 4 stories respectively in your past 3 sprints, then you know that your velocity is 2-5, not 3 or 4. This range will allow you to communicate your best case scenario and your worst case scenario to your stakeholders instead of committing to one single number that is most likely wrong. Always use velocity as a range when communicating outside your team.

In short, velocity is how fast you are developing your software.

Some more resources:
An extensive example and definition of velocity.
A simple definition of velocity:
The mathematical definition of velocity (from Physics).

My thinking on velocity and Agile Estimation has evolved

If you want to know what I have learned since I wrote this article, check out my #NoEstimates white paper and the following articles:

• Simple estimation techniques work! Use the data you already have
• Story Points considered harmful, or why the future of estimation is really in our past
• A better way to predict project release date
• Focus on what matters, a #NoEstimates advocacy post
• The #NoEstimates how to