What is a sprint?

In the project and software development world, the term "sprint" is used with the word "scrum". 

Wikipedia defines "Scrum Sprint" as ...a repeatable fixed time-box during which a "Done" product of the highest possible value is created. Sprint lies at the core of the Sprint agile methodology and can be thought of as an event which wraps all other Scrum events like Daily Scrums, Scrum Review and Sprint Retrospective.

Unless you're already involved with this term, this first line definition is not very helpful. Here's my shot at it for

• Agile
• Scrum
• Sprint

Let's start with the word "agile". I take this word literally. Agile means flexible and loose, not ridged.

Ok, now the word "scrum". In product development, scrum is a framework or methodology to getting work (new features, improvements, bug fixes) done in a flexible way (think agile) and quickly released to the end customer. At the core of this approach is getting some initial ideas down, building them, then delivering them to the end users, all within a specified time, such as a week, two weeks, or one month. And then doing it again for the next set of ideas. These ideas for new work can be predefined in a "backlog" list of todos, but can also come from the end users after they have played around with the past delivered items. 

Cool. So, when I said "a specified time", that would be called a "sprint". A sprint is just an agreed period, such as one week, for building and delivering the new features, improvements, or bug fixes out to production for the end users. This period is time-boxed, meaning that we do our best to plan what will be done in that period (i.e, this week) and then whatever we have done at the end of that period, we release to the customer. Anything not done will get pushed out to the next sprint, or period (i.e., the following week). We don't change the length of this period. Instead we stick to the length and release what we can get done. At PieMatrix, we do weekly sprints and deliver every Friday. However, sometimes we deliver more than once during a week if needed for important fixes.

As you can see, this is a repetitive and incremental way of delivering pieces of a larger total solution.

This entire agile way of working is the oposite of spending time up front defining all of the things we need to do, building them until they are all done, and then delivering them all at once to the end customer users as a big bang. Instead, agile is doing small increments and refining as we go along.

I'm not saying the big bang approach is wrong. That has its place, especially when all requirements are solidly known and the project size is not that large.

When should we use the agile scrum method with sprints? The best condition is when:

• We don't know all of the initial requirements up front,
• Or if we have a good idea, we would like to get some quick wins with frequent small releases over time to help the end user adapt, and
• We would like early feedback from the end users so we can improve or refine what to do next

There are other terms that I will not cover, but you can find glossary information at scrum.org.