about shortening the scrum events
A Scrum event can be shorten, for ex the Daily Scrum is finished in 5-10 mins, instead of 15 or the Sprint review finished in 2 hours, instead of 4.
Then the team returns to development tasks, right?
Taking the Sprint Review as an example,
"This is at most a four-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter." - Scrum Guide (2017)
If your Sprint is 2-week long, then the event should not take more than 2-hour.
The Scrum Guide doesn't dictate the minimum time required for each event. However, if the Scrum Team were to finish any event way faster than the recommended time-box (eg. 30-minute for a 2-week Sprint Review), then the question will be if the event was done effectively and includes the following elements as stated in the Scrum Guide.
- Attendees include the Scrum Team and key stakeholders invited by the Product Owner;
- The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”;
- The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
- The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;
- The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed);
- The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
- Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,
- Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.
thank you Cheng Fu Yeo, for the answer.
yes, agree with your comments,
but my question is - what should we do if all the points are done in sort time, and we have extra time.
what should we do with this extra time, continue our development process, or something else?
I try to learn from experience how long it takes for a Sprint Review (this will of course vary per product, stakeholders, team members, etc). But on average if it requires 60 minutes, then you can schedule it appropriately.
I would expect the Sprint Retrospective to be scheduled very soon after the Sprint Review finishes (perhaps with a short break in between.
Or if one day ends with the Sprint Review, the next should probably begin with the Sprint Retrospective.
It's not efficient to have large gaps in between the events, but it's not necessarily a good idea to focus too heavily on utilizing that time.
Normally team members will find something useful to do in the time between a Sprint Review that finishes early, and the Sprint Retrospective. Some suggestions:
- Continue working on in-progress items
- Refine items towards the top of the backlog (perhaps based on feedback from the Sprint Review)
- Start working on an item from the top of the backlog
- Improve quality. e.g in software development, the developers may make small refactors or improve test coverage
- Use the time for personal development
- Use the time for personal chores
- Relax, to enable better focus at the Sprint Retrospective
thank you Simon Mayer,
Your answer is very detailed and clear. I got the full answer to my question.