views:

2118

answers:

7
  1. Is there a difference between Sprint and an Iteration or one can have Iterations within a Sprint or Sprint is just the terminology used instead of Iteration in Scrum? It will be helpful if someone can throw some light on this.

  2. Suppose there are 4 sprints and you have decided the first sprint will go up to 10 days is it required that other 3 sprints should have the same length of the 1st decided sprint's length??.

A: 

Sprint == Iteration.

The lengths can vary, but it's a bad planning precedent to let them vary too much.

Keep them consistent in duration and you will get better at planning and delivering. Everything will be measured by how many 10-day sprints it takes to finish a series of use cases.

Keep them consistent in length and you can plan your deliveries, end-user testing, etc., with more accuracy.

The point is to release on time at a consistent pace. A regular schedule makes management slightly simpler and more predictable.

S.Lott
A: 
  1. Sprint is just the term for an iteration.
  2. You can change the Sprint length to be anything you want, but likely you'll want to try to find an amount of time that "works well" (which may mean any number of things for your team) and end up sticking with it over time.
matt b
A: 

The important thing about a sprint is that: within a sprint the functionality that is to be delivered is fixed.

A sprint is normally an iteration. But you can for example have a 4 week sprint, but have 4 one week "internal" iterations within that sprint.

There is a lot of discussion about the length of sprints. I think that if you do it according to the book they should all be the same length.

We have found that a short first sprint to get the development environment up and running, followed by longer basic functionality sprints, then short sprints towards the end of the project, has worked for us.

Shiraz Bhaiji
+4  A: 

All sprints are iterations but not all iterations are sprints. Iteration is a common term in iterative and incremental development (IID). Scrum is one specialized flavor of IID so it makes sense to specialize the terminology as well. It also helps brand the methodology different from other IID methodologies :)

As to the sprint length: anything goes as long as the sprint is timeboxed i.e. it is finished on the planned date and not "when it's ready". (Or alternatively, in rare occasions, the sprint is terminated prematurely to start a new sprint in case some essential boundary conditions are changed.)

It does help to have the sprints of similar durations. There's less to remember about the sprint schedule and your planning gets more accurate. I like to keep mine at 2 calendar weeks, which will resolve into 8..10 business days outside holiday seasons.

laalto
A: 

Iteration is synonymous with sprint, sprint is just the Scrum terminology.

On the question about sprint length, the only caution I would note is that in Scrum you are using the past sprints to gain a level of predictability on your teams ability to deliver on their commitments for the sprint. They do this by developing a velocity over a number of sprints. A change in the team members or the length of the sprint are factors that will affect the velocity for a sprint, over past sprints.

Just as background, velocity is the sum of estimation points assigned to the backlog items, or stories, that were completely finished during that sprint. Most Agile proponents (Mike Cohn, Ken Schwaber and Jeff Sutherland for instance), recommend that teams use "the recent weather" to base their future estimations on how much they think they can commit to in a sprint. This means using the average from the last few sprints as the basis for an estimate in the upcoming sprint planning session.

Once again, varying the sprint length reduces your teams ability to provide that velocity statistic which the team uses for sprint planning, and the product owner uses for release planning (i.e. predicting when the project will end or what will be in the project at the end).

I recommend Mike Cohn's book on Agile Estimating and Planning to provide an overview of the way sprints, estimation and planning all can fit together.

hoshposh
A: 
  1. Where I work we have 2 Sprints to an Iteration. The Iteration demo is before the business stakeholders that don't want to meet after every Sprint, but that is our interpretation of the terminology. Some places may have the terms having equally meaning, I'm just pointing out that where I work they aren't the same thing.

  2. No, sprints can have varying lengths. Where I work we had a half a Sprint to align our Sprints with the Iterations that others in the project from another department were using.

JB King
A: 

"_ is largely an organizational issue caused by long hours, little down time, and continual peer, customer, and superior surveillance"

No this is not the definition of scrum, it is the wikipedia excerpt on the definition of burnout.

Dont do too many short 10 days sprints. You will burnout your team eventually. Use short sprints where you really need them, and don't do too many in a row. Think long-term. A distance runner always paces themselves for the full race and does sprints in short distances only where it matters.

If you burnout your team you can toss out all them fancy scrum charts, they won't do a thing for your team's plummeting productivity.

McG
What the hell are you saying here? Many teams do use 2 weeks sprint. Yes, a sprint is intense, but this certainly doesn't mean people are working 80 hours per week, that's ridiculous. Why would people get burned out with two weeks sprints? Your answer sounds totally wrong.
Pascal Thivent
Based on experience, most managers don't leave any slack or special do something else breaks in a 2 wk sprints, most try to maximize thinking it makes them look like better managers. For tiny or small projects that complete and people move on, it's one thing but supporting and enhancing products that never end year after year, it's another matter. Continual 2wk sprints on never-ending projects gives one the feeling of a rat running on a wheel in a cage. My point is, in long-term projects is continual 2wk sprint really necessary?? I don't believe that it is.
McG
My second point is just because a lot of people use continual 2wk sprints doesn't make it right. In silicon valley I see many companies calling a simple mirco-managing of developers with daily stand-ups on 2 week dev cycles SCRUM, even though they have no idea what what scrum process actually is.
McG