Why is the Sprint duration fixed but the duration of the other events not?
Hello everyone,
Respect this part of the Scrum guide I have some question:
"Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process."
In a unfrecuency Sprint:
- If the Sprint Goal and the searched increment is achieved before the end date of that Sprint, why couldn't I short the sprint?
- Why the rest of the other events can finish if they achieve their purpose but not the Sprint event?
Thank you!
The Sprint is fixed in duration in order to help a team establish a cadence. If the duration of the sprint is constantly changing, the ability to consistently forecast a body of work to deliver a potentially releasable increment becomes difficult if not impossible. Do you plan for 2 weeks, 2 days? Or do you just decide to build something and take as long as it takes?
If you are finding that you are consistently achieving your Sprint Goal early in the Sprint, could it be that you are able to include more work on a consistent basis?
The other events do not need a specific cadence other than their occurance. Each event is for a specific purpose but only one of the events, the Sprint, has the purpose to produce an increment of value. All of the other events are used to prepare work or to gain feedback based on the work that has been done.
- If the Sprint Goal and the searched increment is achieved before the end date of that Sprint, why couldn't I short the sprint?
- Why the rest of the other events can finish if they achieve their purpose but not the Sprint event?
The Sprint is the time-box for meeting the Sprint Goal. If it were to be shortened, what effect might there then be on predictability and transparency?
Two things to consider here:
- When you do Sprint planning, it is very helpful to have any idea of your team’s velocity. If Sprint durations keep changing, velocity becomes a much more complicated calculation
- If you shorten your Sprint, it would probably mean have to reschedule your Review, Retrospective and next Sprint Planning. The best practice to aim for consistency with the timings of Scrum Events.
However, according to the Scrum Guide, you can re-negotiate the Sprint scope as long as it does not endanger the Sprint Goal.
We normally chuck in a few additional Stories mid-Sprint, if the team are excelling themselves.
Hello,
Q: If the Sprint Goal and the searched increment is achieved before the end date of that Sprint, why couldn't I short the sprint?
Ans: In the Scrum framework, to maintain cadence with all the stakeholders we are working in a fixed-length sprint with a timebox. So, you can get consistent potential increments at the end of each sprint.
Let's discuss one example: assume that there is a two-week sprint so the client knows that on day 14th I've to schedule my calendar for the sprint review meeting. now, you are saying that what if I have completed work on day 10th. Now, Is it good to send mail to a client for informing them that you have completed the sprint earlier? or just think that what the client will think if this type of scenario will occur frequently?
So, if you are new in scrum then you will get some time to maintain velocity. once your velocity would be stable, the team can estimate easily sprint backlog. and if work completed earlier, the team can discuss with PO and can take more adhoc requirements into Sprint Backlog based on priority.
If you have a done increment on the 10th, the PO & Developers can see if there are any other items in the PB that would meet the sprint goal or if there are any improvement PBIs that could be worked on that were created during the last sprint retrospective.
Remember, the scrum team is accountable for creating a done usable increment at least once a sprint, which means that there isnt anything stopping them from creating multiple increments per sprint.