The Sprint
By now, I have mentioned several times already that agile project delivery methods have proven to be most suitable for most of the project areas. Especially, for example, in mobile and web applications software development projects, where technologies and trends are changing or advancing so rapidly that ability to adopt to this change/advancement has become a major key to success.
When we have a further deep dive into the agile methods theory and try to map the documented processes, principles and terminologies with the agile project processes being followed in your project or organisation, you will realise very soon that what you thought of as being an agile project development process is actually a tailored version of one of agile methods; say Scrum (which is used in most cases, KANBAN is also a very popular variant).
You might now wonder why this is. This happens because the agile process which you have been following is the result of the agile process tailoring or agile methods tailoring done to meet the specific needs of the projects executed by your organisation. This tailoring involves some trade-offs, mainly because no project is the same and projects differ in their scale, scope and technical challenge. Obviously the same process will not suit all circumstances. This given makes agile process tailoring is an essential task to receive best possible advantages of the agile process methods in your project.
Being involved in this agile process tailoring sometimes will lead to confusion in the understanding of some of the agile terminologies, which have a similar meaning as scrum or Kanban terms. For example “Sprint” and “Iteration”.
During my work as an agile coach and during the workshops I have conducted I have been asked questions like,
Is there a difference between Sprint and Iteration? Or is Sprint just another term for Iteration?
Can we have Sprints within Iterations or Iterations within Sprints?
In case I am sending an interim release to a client before the planned Sprint release data, shall I call it an Iteration?
As an answer to these questions I have come up with the following principles or descriptions:
An iteration is the generic agile term for a single development or project cycle. It is a common term used in the Iterative and Incremental Development (IID) processes, which I have mentioned before.
Scrum which is a specialised agile method, or we can say specialised implementation of the agile methodology, uses the term Sprint for its iterations, so one development or project cycle in Scrum is called a Sprint.
The term Sprint is a Scrum specific term, this leads to a Sprint being an iteration but not all forms of Iterations are Sprints.
Other agile methods may not use the same term (Sprint) to define Iteration work, but you find that Sprint and Iteration are the two most commonly used terms to describe one of the cycles in the project.
I hope you now understand why a sprint is an iteration, but an iteration is not necessarily a sprint. The picture below will show you what a sprint in the scrum method will look like. In this example you see the sprint has a duration of 30 days.
Each sprint begins with a (sprint) planning meeting. During the meeting, the product owner (the business owner of the project) and the project delivery (scrum) team agree upon exactly what work will be accomplished during the sprint. The project delivery (scrum) team has the final say when it comes to determining how much work can realistically be accomplished during the sprint, and the product owner has the final say on what criteria need to be met for the work to be approved and accepted.
The duration of a sprint is determined by the scrum master and may vary from one project to another. I have found that the shorter the sprint is, the more overhead is added to the project in relation to all the scrum ceremonies needed to be held. As a scrum master you will need to find the balance between delivering business value (at the end of every sprint) and overhead. The scrum master is the team's facilitator. Once the team reaches a consensus for how many days a sprint should last, all future sprints should be the same. Traditionally, a sprint lasts between 2 – 4 weeks.
After a sprint begins, the product owner must step back and let the team do their work. During the sprint, the team holds daily stand up meeting to discuss progress and brainstorm solutions to challenges. The project owner has to attend these meetings, but merely as an observer and to answer questions. The project owner may not make requests for changes during a sprint and only the scrum master or ultimately project manager has the power to interrupt or stop the sprint. I have found in my experience that a sprint cannot be changed. If for whatever reason the content of a sprint needs to be changed, it is best practice to stop or end the current sprint. Have proper scrum ceremonies, like retrospectives and sprint planning for the new sprint with the new content and scope in it. Following this process will prevent frustration and missing information and makes sure the scrum processes are followed as intended
At the end of the sprint, the team presents its completed work to the project owner and the project owner uses the criteria established at the sprint planning meeting to either accept or reject the work.
This leads me to the following definition of a sprint;
“A sprint (or iteration) is the basic unit of development in Scrum. The sprint is a time boxed effort; that is restricted to a specific duration. The duration is fixed in advance for each sprint and is normally between one week and one month, with two weeks being the most common duration. Once a sprint is started there will be no change to the content, scope and activities in the sprint anymore”
The image below will show the scrum process and the sprint and its place in the scrum methodology
