Change the Scrum Guide™
What is Scrum?
Definition of Done
Scrum and Agile Webcasts
Professional Scrum Foundations™
PSF Subject Areas
Professional Scrum Master™
PSM Subject Areas
Professional Scrum Product Owner™
PSPO Subject Areas
Professional Scrum Developer™
PSD Subject Areas
Scrum Open Assessment
Developer Open Assessment
Professional Scrum Master™ Assessments
PSM I Assessment
PSM II Assessment
Professional Scrum Product Owner™ Assessments
PSPO I Assessment
PSPO II Assessment
Professional Scrum Developer™ Assessments
PSD I Assessment
Work With Us
By posting to our forums you are agreeing to the
Last Post 09 Jan 2014 02:22 PM by Sandeep Kamat. 5 Replies.
Most Recent First
You are not authorized to post a reply.
29 Dec 2013 09:36 PM
Every meeting in Scrum is strictly time-boxed. This means, it has a maximum duration. It does not means that it needs to occupy this full time. So we can stop when purpose is served. But in case of Sprint , it is over only when the time-box is expired.
Based on the SCRUM GUIDE I understood "sprint" which is a container for all other events is also an event.
My first question is: was my understanding correct ? Does SCRUM really consider "sprint" as an event?
Having set that , when a Sprint of 4 weeks length has created “Done”, useable, and potentially releasable product Increment (it has committed during sprint planning to the PO and SM) way ahead of the sprint expiration time say in 3 weeks time (of course the estimation may be wrong or the team may not be experienced or anything else for the wrong estimation),but usually we do pull some more Backlog items to work in the time remaining in the time-box by discussing with PO which is contrary with other events viz., sprint planning , Sprint Review and Retro (In such case here we stop meeting).
Please clarify what is the correct way of doing as a SCRUM purist.
29 Dec 2013 11:23 PM
You are correct on all your assumption. Scrum is all about learning and adapting as early as you can. You may have multiple teams working in parallel on the same product which requires all teams to follow the same sprint cadence and you can not break it. Also for a new team over or under commitment is a part of learning which requires backlog or future sprint duration adjustment accordingly.
A meeting is an internal team event which can be adjusted per team's discussion while a sprint re-adjustment involves other stakeholders and your customers and you can not invite them without a prior notice
The duration of the scrum events were defined based on the best judgement e.g. 15 mins standup for a 7+/-2 members team, similar for planning and review meetings etc.. The sprint duration is defined by team and they can adjust it but should not vary between sprints.
30 Dec 2013 02:33 AM
> Does SCRUM really consider "sprint" as an event?
Yes, a Sprint is a time-boxed event in Scrum
> usually we do pull some more Backlog items
> to work in the time remaining in the time-box
> by discussing with PO which is contrary with
> other events
That's fine; the point is that the team don't *have* to do this. They could spend the remainder of the time-box on activities that are unrelated to the Product Backlog.
Om Prakash Bang
30 Dec 2013 06:51 AM
What are the other activities unrelated to the Product Backlog on which team can spend time ?
Do you think, following are the activities on which team can work ?
1. Work with Product Owner to refine user stories in Product Backlog.
3. Update any living documents.
4. Work to reduce technical debt.
30 Dec 2013 09:51 AM
> What are the other activities unrelated to the
> Product Backlog on which team can spend time ?
Anything legal and which won't get them fired, basically. Once the Sprint Goal has been achieved a Development Team can do what it wants.
Most do in fact choose to bring work forward from the Product Backlog as you suggest, or to pair down any technical debt that has been incurred. Product Backlog grooming is another worthwhile activity.
09 Jan 2014 02:22 PM
In my experience, time boxing aspect of Scrum is probably the most challenging part to get right and I would not put emphasis on it until sprint 3 or 4. Focusing on mastering other aspects of Scrum during the initial sprints is probably more useful.
One thing that has frequently come up during retrospectives with respect to pulling in backlog items mid-sprint is that not all stakeholders are made aware of those or that they do not go through the same rigor as when items are pulled in during the sprint planning session.
You are not authorized to post a reply.