Scrum

Overview (From Wikipedia, ControlChaos and Scrum for Team Systems)

Scrum is an agile method for project management. Its intended use is for management of software development projects, and it has been successfully used to "wrap" Extreme Programming and other development methodologies. However, it can theoretically be applied to any context where a group of people need to work together to achieve a common goal - such as setting up a small school, scientific research projects or planning a wedding.

Characteristics:

• A living backlog of prioritized work to be done
• Completion of a largely fixed set of backlog items in a series of short iterations or sprints
• A brief daily scrum, a meeting at which progress is explained, upcoming work is described and impediments are raised.
• A brief planning session in which the backlog items for the sprint will be defined.
• A brief heartbeat retrospective, at which all team members reflect about the past sprint.

Click the picture for a much more detailed explenation of all the elements:

Scrum for the Order Management Expert Group

Why we need our own Scrum process

As with all processes, they don't fit everywhere. Scrum is targeted for teams, that closely work together, but that does not mean, that we cannot take the best of it and adopt it to our situation, which is special for a number of reasons:

• We don't have a product owner, who represents the customer and decides about the features that shall go into the product. We don't even have customers yet!
• It's hard (or better impossible) to have daily scrum meetings for the simple reason that the shape of our earth let's us all live in different timezones. (Life in international projects could be so much easier, when the earth were flat!)
• The ability to contribute to the team effort does not only vary from person to person in the team, but also for every single members there are times when it's impossible to spend a single hour on our work, but there are also times when there's some time to contribute
• The optimal team size is somewhat around 6-8 people, we're significantly more than that, but splitting up is not really an option, because of the workload variations mentioned above

How we will implement Scrum

• For Product Backlogs and Sprint Planning, we will use ScrumWiki, which is a wiki (UseMod^?) with some special extensions for Scrum. It's setup at our own server:
  • ScrumWiki for JSR264 (login credentials are only known to the expert group)

• To get an overview about how much everybody can contribute to a Sprint, we have to estimate our hour bank beforehand:
  • Hourbanks

• The Product Backlog, i.e. list and priorization, is not owned by the Product owner, as there is none, but by the collective of the team, maybe we need to introduce an editor.

• We will have sprints of 2 weeks duration. (If this will show to short or long, we can still change that of course)

• Sprint planning:
  • get hourbank planned BEFORE the sprint planning conference call, everybody who did not react is counted with zero hours for the next two weeks. Nevertheless, people shoule be able to join during the Sprint, but then have to work on items in the sprint backlog.
  • Have the sprint planning conference call on Thursday, before the sprint is over. This will give people, who are not on the call, a chance to comment on it. By Monday morning the team must have come to an agreement about the scope of the sprint.
  • estimate complexity of product backlog items.
    • use IEHs as measurement (ideal engineering hours, i.e. how long it would take you ideally without any interruptions or problems)
    • estimates are done usinging non-linear fibonacci numbers: 2,3,5,8,13
    • every task that is more complex than 13 IEHs has to be broken down into subtasks!
  • get team commitment to tasks. By monday the scrum master will send out a mail to the team to summarize what the team has commited to, either implicitly or explicitly.

• Sprint-Backlog
  • maintained by everybody on the ScrumWiki for JSR264
  • Only tasks on the Sprint-Backlog are worked on during the Iteration
  • Still, missing tasks can be added, if they are needed to keep the commitment to the Sprint goals.

• Daily-Scrum
  • not daily, have four scrums during a spring:
  • informal, no minutes, no internet connection (roughly two working days between each of the calls)
    1. wednesday morning
    2. thursday evening
    3. tuesday morning
    4. wednesday evening
  • invitations go to all the experts, so nobody feels excluded and everybody can still join during the sprint.

• Lessons Learned
  • for convenience, it will be done at the same time as the sprint planning for the next iteration
  • what have we done well, what can be improved, which are the actions?

• Sprint timeline
  • 1st week, monday: START
  • 1st week, tuesday:
  • 1st week, wednesday: Scrum in the morning
  • 1st week, thurday: Scrum in the evening
  • 1st week, friday:
  • 2nd week, monday:
  • 2nd week, tuesday: Scrum in the morning
  • 2nd week, wednesday: Scrum in the evening
  • 2nd week, thurday: Lessons Learned & Sprint planning for the next Sprint
  • 2nd week, friday: Celebration of finished Sprint

• TODO:
  • How do we handle an impediment backlog?