Pick one:
- Yes, it is ok, the team needs to be managed by the Scrum Master who decides when to adjust.
- Yes, if the Product Owner approves
- No, use the time box to help detect when things are not well understood and where clarity is needed. Time boxes bring rhythm
- Sometimes, if the Product Owner and Scrum Master agree
A time box is a common practice underlying most agile processes especially, Scrum. Time boxing is a the closest thing in agile or scrum that we have to something that is clearly a best practice. Most managers or early adopters of Scrum wonder what they do to create a sense of urgency and the answer is simple “Time Box”.
In Scrum we have 6 formal timeboxes.
- Release Planning
- Sprint Planning
- Sprint
- Daily Standup
- Sprint Review
- Sprint Retrospective
Time boxes are a key element in Scrum. They form the a bases for how we manage the team’s energy. The general rule in using time boxes is to not adjust the time once you have set it. When the clock runs out the bell “dings” and things change.
#1 mistake those new to Scrum make is to adjust the sprint length to give the team more time to complete their work. Basic Scrum training should cover and provide an in depth explanation of why not to adjust the time box.
Hi Joe ScrumMaster,
To keep your profile active you need to review the guidelines here.
http://www.scrumalliance.org/CSM
The Scrum Alliance has recently a
dded/modified its existing program for CSP Certified Scrum Professional and you could look at applying for that if you have been using Scrum.
- Scrum Coach
On 04/30/10 10:05 PM, Joe ScrumMaster wrote:
——————–
Hello Scrum Coach,
I took your ScrumMaster course last May. What, if anything, do I need to do to keep my ScrumMaster certification active?
Thanks,
Joe Scrum Master
Below is a conversation between Joe ScrumMaster and Scrum Coach.
——————————————————————–
On Fri, Apr 30, 2010 at 7:21 AM, Joe ScrumMaster wrote:
Hi Scrum Coach,
I have question for you regarding the Sprint Retrospective. Should the notes a ScrumMaster take during this meeting be publically posted for interested folks to read?
Thanks,
Joe Scrum Master
——————————————————————–
Hi Joe Scrum Master,
Good to hear from you.
I would be careful with this kind of information. Focus instead on what
scrum goals came out of the team meeting. Sensitive conversations need to be handled gingerly. Some of them can blow up into an HR issue. If it were me I would like an opportunity to get better without being public-ally embarrassed. As long as you (
ScrumMaster) see a movement to improve then let people improve with grace.
Focus on team goals and key learnings. It is not a data thing. We are dealing with a system of people and the message matters.
All of the observations a ScrumMaster might take should not be made public.
Hope that helps.
- Scrum Coach
Do you agree?
What is the basic building block in applied Scrum?
Choose:
- Team
- Individuals
- Practices
- Scrum Team
- Scrum Framework
The Scrum Team is self organizing, self managed, cross functional and self aware. Organizations using scrum rely on the basic building block of a Scrum Team to understand how to it can be applied in their context. There is an assumption here that the team exists for some purpose and they have been assembled. So the team is not self assembling. The Scrum Team figures out how to do its work, manages itself to do the job, has all the skills necessary to get the job done and uses its values to deepen its understanding of self to perform better as a well formed team.
Do I want any force that causes quality to go down?
New to Scrum? Find more questions by reading our Scrum FAQ
Choose
- The development team creates a spec.
- The Product Owner says it is.
- The business asks for it.
- There is a test which actually requires it to be there and fails when it is not.
Comment: We often find ourselves lost in the desirements trying to find the real requirements for our system. Those things which seem required often end up being only desired. The word requirement has suffered more from confusion and misuse than just about any other word in the IT lexicon of development. What is a “nice to have” requirement? I mean really! I have close to 20 years of experience in the industry including training and writing requirements. Even with all of that experience the word still makes me a little crazy. I like the word desirement because of it’s contrast with requirement. When there is a test that makes it required with a pass/fail then it is a requirement, until then it’s just a a desirement.
So, a more interesting question is …. When is a requirement truly required?
Choose:
- The PO says go.
- The Teams says they are ready.
- The SM has determined a time box for the sprint.
- The team and PO agree to a time box
- The PO understands and is prepared to talk about the stories
Comment: There are a number of things you should do before you can even begin planning. The most important thing you can do is make sure that your Product Owner is prepared, and understands what the stories are about. Remember that the Product Owner is a role here, so what we’re actually saying is that someone on the Team knows about each story; that is, each story has its own champion (Story Owner) who represents the Stakeholder’s needs/wants to the Team. This may require that the Product Owner (person) coordinates the
- You get past work experience. And calculate the amount of work the team can handle
- Get estimates from the team and double the number they give you to determine work load.
- Meet with each individual and see how much work they can take on. Build a sprint plan from that information. Then gather everyone, show the sprint plan and kickoff the team sprint.
- Use the PO/SM powers to challenge the team to take big bites. Get as much loaded in the sprint as possible. The PO/SM can form a powerful pincer to overcome resistance.
- This is sprint planning. You commit one story at a time. Make sure the team is committing to sharp definitions of done.
Comment: After a Story is committed to, the Team (with the PO in the lead) has the option to reprioritize the Story list, and the Team takes the next one to consider. Once again, the Team comes to the “doneness” Agreement and commits to adding the Story to the list of already-committed-to Stories. This process is repeated until the Sprint is “full” and the Sprint Plan is complete.
It is never too large for the sprint. The team must learn how to meet business expectations.- The team cannot agree on which stories to work on during the sprint
- The product owner has prioritized the story into sprint planning without any written definition of done
- When the team cannot agree on how to commit to the story
- Teams are inherently anxious; SM/PO must challenge the team and not accept no for an answer.
- Make the sprint bigger so the story fits.
Comment: The Team may not be able to commit to a story, or might noteven be able to agree on “done.” This makes the story in question is an epic, by definition, and the Team must decide what to do. Typical choices include committing to an Analysis Story to figure out what to do about the epic, or extracting a smaller story from the epic to do instead (putting the remainder back on the backlog), or skipping the story altogether and moving to the next one. Bottom line: We need a sense of movement to understand what the team can and cannot do. Biting off chunks of work that are too large obscures movement and makes throughput / velocity that much harder to understand. Use the team’s ability to commit to understand the work that the story represents.
Yes, It’s their process why not?- No, explain to them and work through why the retrospective is so important.
- Maybe, if they are no longer a team then why continue with Scrum?
- Only do retrospectives once a quarter and build up a good list of things to change.
- Yes, the process will take care of itself we don’t need to watch it that closely. After all it’s common sense!
Comment: Of things to watch out for and not allow this is high on my list. It boils down to this rule: If the team is not doing a retrospective then they are not doing scrum. The retrospective is where the team takes formal ownership of their process. In these situations I crack shins, and kick knee caps and generally do what is necessary to ensure they continue doing a retrospective. Without that we often see teams fall into “it’s not my fault” because “x” told me to. In some cases “x” is the process that no-one owns, imagine the process that gets created by someone who decides to own it but, does not do it themselves!.
Retrospective is an external constraint that must be demanded of the team. There are many ways to run a good retrospective, ScrumMaster rise to the challenge and support your team.
A time box is a common practice underlying most agile processes especially, Scrum. Time boxing is a the closest thing in agile or scrum that we have to something that is clearly a best practice. Most managers or early adopters of Scrum wonder what they do to create a sense of urgency and the answer is simple “Time Box”.
