Monday, February 16, 2009

ScrumMaster Certification FAQ

People have been sending questions about the Certified Scrum Master for Video Game workshop. Below are some common Q&A:
  • Where and when is the workshop?
    Monday (3/23) and Tuesday (3/24). It's located at the International Hotel (across the street from Moscone). It runs from 8:30 AM to 5 PM each day.
  • Is there still room in the workshop?
    Yes. It's about half full.
  • What does the workshop cost?
    $1500 per attendee. There is a 10% discount when you send three or more.
  • Is there an agenda?
    Yes, you can see the outline here. A more detailed agenda will be sent out prior to the class in email.
  • Is this for people who have never used Scrum or those who have Scrum experience?
    The class typically has both. I suggest to attendees new to Scrum to read up on Scrum before the class, but that is not a strict requirement. There is a lot of information to absorb over two days and it's more valuable to focus on the principles of Scrum rather than just the basic definitions. I do cover the basics though.
  • How is this workshop different from the other Certified Scrum Master courses?
    This is the only course with material and exercises specifically aimed at video game development. You'll learn the same principles of Scrum but you'll benefit from half a decade of practical application to our industry.
  • How much of the workshop is instruction and how much hands on exercise?
    Almost 50/50. Hands on team work once an hour is very effective in learning these practices.
  • What does the "certified" part mean?
    It means you'll be certified/recognized as a Scrum Master by the Scrum Alliance. Following the course you will receive a certificate and a one year membership in the Alliance.
Any other question? Please let me know. See you in San Francisco!

Wednesday, February 11, 2009

How long should a sprint be?

What is the ideal length of a sprint? Sprints typically last two to four weeks, but many factors influence this::
  • The frequency of customer feedback
  • The experience level of the team
  • The time overhead for planning and reviews
  • The ability to plan the entire sprint
  • Balancing the intensity of the team over the sprint
Customer Feedback
The duration of a sprint depends on the amount of time the customers can go without seeing progress and providing input, or direction on the game. Some core mechanics require frequent feedback in the early stages of development, so a shorter sprint is required to be sure the game is headed in the right direction. Some teams don’t need such a rapid cycle of feedback (e.g. production teams) so a longer sprint is better for them.

The key idea is that the team must not have their goals changed within the sprint. If four weeks is unbearably long for customers to wait for a review, then they need to demand a shorter sprint.

Team Experience
The experience level of a team influences the length of an sprint. Teams that are new to game development, agile, or working together, should start with shorter sprints. This allows them to iterate on the practices and learn how to iterate properly. Teams that are new to Scrum should be discouraged from practicing longer sprints. New teams will generally approach a sprint like a mini-waterfall project; (see Figure below) inexperienced scrum teams will still approach development sequentially (one activity after the other). They’ll spend a couple of days exclusively in design, a few weeks creating code and assets and finally integrate, test and tune during the last few days of the sprint. They end up crunching at the end of the sprint to reach the finish line. This doesn’t give them the opportunity to achieve the best possible result.

Experienced teams will perform these activities more in parallel. Working this way creates better results and allows the team to iterate more during the sprint.

Planning and review overhead
Shorter sprints require a larger portion of a team’s time for planning and review meetings. Review and planning usually require a good portion of a day regardless of the length of the sprint. Even though planning for a shorter sprint may take less time, the remainder of the day following the meeting is never 100% effective. Imagine that you had a sprint that lasted one week. You’d probably spend one day that week in review and planning. That’s 20% of overhead!

Plan to party - Allow the team to have a little celebration time between sprints. Besides, game developers don’t need much excuse for a party!

Ability to plan the sprint
If the sprint goal is uncertain: if experimentation or prototypes need to be done then the sprint should be shorter. Uncertainty implies that the work required might be significantly different from the one anticipated at the start of the sprint. If this is the case, it’s better to change direction after two weeks than four.

Prototype sprinting - Some prototype teams have chosen extremely short sprint times of days!

Balanced Intensity
Sometimes four weeks is too long for a sprint. This is especially true of teams that are new to agile. As described above, new teams will work sequentially during sprints. This leads to a low intensity mini-design phase up front and a high intensity debug mini-crunch phase at the end. While the “mini-crunch” isn’t going to kill anyone, it’s not the most efficient way to work.
Teams will find what works best for them.

Choosing a sprint duration - On my last team, two week sprints felt too short. It was as though the review was too soon to “do anything too challenging”. A four-week sprint was too long to create a sense of urgency. We compromised and chose a three-week sprint because “it felt right.”

When is the sprint too long?
A product owner will usually limit a Sprint’s length to four weeks. Some may argue that some technical areas (e.g. engine or pipeline development) cannot achieve any significant progress in as little as four weeks. The need for longer sprints to show value is usually an indication that the technical practices need to change. Any development practice that can’t demonstrate progress at least once a month should be changed. Interim goals can demonstrate a reduction and have value. The longer a team goes without proving or disproving architectural assumptions, the greater the potential waste.

Who selects the sprint duration and when?
The customers and the team needs to be determine the duration of the sprint. If there is a disagreement, the product owner has the final say. The length of the sprint can only be changed between sprints and shouldn’t change frequently. Frequent changes to the length of sprints can be disruptive. It takes time for teams to adjust to this change; the rhythm and pace of a particular sprint length takes some time for the team to adjust to.

Whatever the duration you choose, don't be afraid to change it throughout the project. The conditions listed above will change.