What should we call sprints in agile development when not selling consulting to a client?

Question

Obviously, calling sprints "sprints" would be one option, but even though that is well known and might convey an image of working really hard and getting a lot done, it also might imply "moving as fast as you can without regard to fatigue". And even though people directly involved in the sprints can be expected to understand this, managers not directly involved in the sprints might think that sprints involve, well, sprinting.

I believe that when the original term was coined it was in the context of performing consulting for clients at an hourly rate, which might be part of the motivation for naming it a sprint. Sort of an "at $200/hour you had better be sprinting" kind of thing. But in this case, clients buy the software, not the time, so they don't really care if we are sprinting or not.

So what's a good name for a sprint that won't tempt people to think it means working as hard as we can without pause until we drop?

And, before anyone points it out in an answer, there are lots of great ways to educate people on a good agile process, but this question isn't about that. This is about naming sprints in a way that helps as much as possible to educate people about a good agile process by means of the name alone.

Answer 1

I would refer to these as "Iterations." You can describe your process in terms of iterations to your clients -- e.g. We work in two week iterations. That means, on day one, we identify the work we're going to do in the next two weeks.... etc...

Answer 2

Public Sector Terms

Every industry and sector has its own patois. In the public sector, agile practices are generally referred to as "modular development," and sprints deliver "increments" or "useful segments." See page 7 of Contracting Guidance to Support Modular Development for an example.

Private Sector Terms

For companies that understand agile practices, it's still often useful to define the terms as you mean to use them. For my clients, I generally define agile frameworks (e.g. Scrum) as:

An iterative process (or set of processes) where the goal of each iteration is to complete a demonstrable increment of user-visible functionality.

I'm sure other people have said similar things, but the quote above is mine, so I have no external reference for it. I simply find it useful to define my terms with people so that, regardless of what we decide to call it amongst ourselves, we at least theoretically agree on the actual objective.

See Also

• http://www.cio.gov/documents/25-point-implementation-plan-to-reform-federal%20it.pdf
• http://scrum.jeffsutherland.com/2010/01/iterative-vs-incremental-development.html

Answer 3

From the Scrum perspective, the Sprint is not just an iteration. It has commitment (planning) and accountability (demo) as well.

If you change the terminology you won't be able to communicate with other practitioners. If management doesn't understand the definition of Sprint and stops at the terminology, they may think that Scrum means that the developers will go into a formation and to this every morning:

My point is that don't change an existing name because it is easier to sell something. Sell the idea not the name. People don't buy a certain kind of product, because it was made by a company named after a fruit. They buy because the idea what it represents: reliability, status symbolism etc.

Based on my experience, most of the managers are smart and they know the difference and will understand the meaning of a Sprint.

Answer 4

I don't think you really need to worry about the semantics. "Sprint" is fairly standard terminology, and the clients will care more about the end sprint review/burndown charts etc. As long as the work is being done, what's in a name?

Having said this, if you really must change the name, how about timebox? If you use the DSDM agile terminology, you can split the project down into iterative cycles, and then break the iterations down into timeboxes. This is the same thing as 'sprint' but with a different name.

Answer 5

How about "Time-boxed work packages"?

Answer 6

What is the perspective of what you call a sprint for your customer? Does the customer have visibility and receive a deliverable that he evaluates and needs to approve? Does he provide feedback about the product that you consider for future releases? Is the product defined in a clear and closed way enough to finish the development? In my opinion, you should get on your customer feet's to name it in a way that it makes sense to him and be also clear enough for the team to understand the customer perspective. Without more information, you can maybe call it 'release', 'version' or something similar. The topic is important as will more likely describe and help to meet expectations.