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.

1. Release Planning
2. Sprint Planning
3. Sprint
4. Daily Standup
5. Sprint Review
6. 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.

To keep your profile active you need to review the guidelines here.

http://www.scrumalliance.org/CSM

The Scrum Alliance has recently added/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

——————————————————————–

Choose:

1. Team
2. Individuals
3. Practices
4. Scrum Team
5. 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.

New to Scrum? Find more questions by reading our Scrum FAQ

1. The development team creates a spec.
2. The Product Owner says it is.
3. The business asks for it.
4. 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?

1. The PO says go.
2. The Teams says they are ready.
3. The SM has determined a time box for the sprint.
4. The team and PO agree to a time box
5. 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

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.

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?

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.