The Sprint is one of the five events in Scrum. Like all Scrum events, the Sprint is also time boxed. The maximal duration is four weeks (usually you have Sprints of two weeks).
So basically, a sprint is a time frame, which contains and consists of:
the other Scrum events:
the planning meeting
the daily stand-ups
the review meeting and
the retro meeting
and the development work
A typical Sprint duration is two weeks and its duration is consistent, so if you choose your sprint time box to be two weeks, you should stick to that.
In this time, potentially releasable product increment is created. This means that at the end of each sprint, one part of the product is completed, it is ‘done’. 'Potentially releasable' means that this part can be release, but does not have to be.
But how do we get there?
We start every sprint with a planning meeting.
In this meeting, the team commits to a sprint goal - so what we want to achieve - and a sprint backlog with tasks - so a plan how we want to achieve this goal.
Once we’ve agreed on that, the development teams starts developing the product increment.
During the sprint
no changes are made that would endanger the goal
the quality goals do not decrease
scope may be clarified as more is learned
So what we do is: We commit to a plan for a short time period and we try to stick to that.
During the sprint, the dev team has a short daily meeting - the daily stand-up - to plan the next 24 hours in order to achieve the sprint goal.
At the end of each sprint, the potentially releasable product increment is presented in the review meeting.
A sprint ends with a retro meeting, where we focus on people, relationships, processes, tools etc. and identify potentials.
A new Sprint starts immediately after the conclusion of the previous Sprint, so it starts all over again.
How do Sprints enable High Performance Teams?
Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every few weeks
this means that you plan a time frame for two weeks, which is quite predictable - so the team can deliver what they promise
also, the team receives regular feedback from the Product Owner and the stakeholders if the development is on the right way of if some adjustments are needed
and, sprints give us the opportunity to make ongoing adaptations on the product, which results in a more valuable product
Also, the dev team is part of the whole process, which on the one hand increases their commitment and motivation and on the other hand, it improves the product as more experts are part of its evolution.
And we have a strong alignment, as we define sprint goals every two weeks, our mission and goals are very present and lead us to a great product.
Inputs, wishes, ideas?
Drop me a line: