Part 4: Events

In 2016 my wife and I married. In order to support the planning of the wedding, I introduced Scrum. In this blog, I will share our experience of this experiment.

This is the fourth out of 5 parts. In this part I will describe how we customized the Scrum events to fit our needs.These are the other parts of this blog:

• Part 1: Motivation and the context of wedding planning
• Part 2: Roles
• Part 3: Artefacts
• Part 5: The definition of “Done” and the conclusion

Events

In this chapter I will discuss the events which occurred during a sprint and how we adapted some of them to satisfy our needs.

The Sprint

In Scrum the timeline is a theoretically infinite sequence of sprints. A sprint takes a given time (e. g. a fortnight or a month). After the end of a sprint a shippable product is supposed to be available which contains all the features added during the sprint.

In our case, each month from May 2015 to May 2016 represented a sprint. This seems to be an appropriate sprint duration in the context of wedding planning because sprints of this duration were neither empty of working items nor did they contain that many working items that handling them would become extremely complicated.

In Scrum, there are things you are not allowed to do. You should neither postpone working items (e. g. because requirements have changed or you notice that you cannot complete them within the sprint) nor should process working items not scheduled to the current sprint. If the planning has become obsolete the current sprint must be cancelled and a new sprint must start.

My wife and I decided that these no-goes were acceptable in our context. As mentioned before, our sprints were not meant to allocate our full leisure time. Each sprint had time reserves. This is different to the ordinary Scrum context. There, the entire (working) time is planned so there are not any planned time reserves for adding working items to a sprint in progress.

For instance, my wife and I decided to visit various jewellers at their shops and at some wedding fairs during the sprints 10/2015, 11/2015 and 12/2015 in order to invite offers for the rings. We planned to order the rings in sprint 04/2016 and to purchase them in 05/2016. By chance, we found our rings for a reasonable price at the end of sprint 10/2015. Consequently, we ordered them during that sprint and bought them during sprint 12/2015.

If we had stuck to the Scrum principles we would have had to wait at least for sprint 11/2016 to order the rings which did not make sense because we had the time reserves to evaluate and accept the offer in sprint 10/2015. In this case complexity was reduced by eliminating a working item by completion ahead of schedule.

In standard Scrum, postponing or cancelling a working item destroys the sprint plan and therefore leads to cancelling the entire sprint.

In our context, postponing a working item was acceptable because of the time reserves available in the next sprint. If too many working items had already been planned for a consecutive sprint (as we could realize by viewing the working items of the next sprint at the whiteboard) we were discouraged from postponing those items of the current sprint.

Cancelling a working item was no issue either. This just increased the time reserves of the current sprint.

The pseudo sprint Ongoing

We introduced a special sprint called Ongoing which does not exist in the Scrum framework. Working items in that sprint were supposed to be processed in more than one sprint. So placing them into the sprint Ongoing was just an abbreviation for creating multiple copies Working Item Part 1, Working Item Part 2, … Working Item Part n and placing them into different consecutive sprints.

The working items placed into the pseudo sprint Ongoing were:

• collecting ideas for the invitation cards (sprint 05/2015 to 11/2015)
• collecting ideas for the wedding celebration (sprint 05/2015 to 03/2016)
• collecting ideas for the music being played (sprint 05/2015 to 04/2016)
• dancing class (sprint 07/2015 to 05/2016)

We just added working items to the sprint Ongoing which were expected to take some time exceeding the sprint limit (the dancing class) or which should re-occur regularly up to a certain time (all working items for collecting ideas).

Sprint Planning

Usually, a new sprint begins with a Sprint planning event which is used for estimating sessions and picking the working items for the current sprint.

Estimating working items

Estimating working items in the context of wedding planning is rather straight forward. We usually did it implicitly while adding working items to the Product Backlog.

Some working items were completed by doing a phone call or writing an email (e. g. making appointments or gathering documents for the registry office).

Preparation working items (for preparing or following-up appointments) usually took one to three hours while the appointment itself usually took between one hour (e. g. applying for marriage at the local registry office) and a day (e. g. meetings with service providers in the countryside where the wedding celebration was supposed to take place, visiting wedding fairs and visiting outfitters).

So it was sufficient in our case to do a raw estimation while adding the working items to the Product Backlog.

Adding working items to the current sprint

Some working items were already assigned to sprints in the stakeholders and product owner phases. During the Sprint Planning my wife and I discussed whether theses assignments were still valid. If that was not the case we reassigned those working items to a different sprint.

Then we had a look at the quantity of working items for the current sprint. If just a few working items needed to be completed we discussed if and what working items could be added to the current sprint which had been assigned to a later sprint before.

If we considered the workload of the current sprint to heavy we discussed the possibility of postponing the completion of working items to a later sprint.

At the end of the discussion we cleared the whiteboard (which contained the working items of the previous sprint plus a look-ahead view of the current sprint) and added the working items of the current sprint to the Sprint Backlog.

Then we also added the expected working items of the next sprint to the whiteboard. This was just meant to be an informative preview of what was supposed to be done right after the completion of the current sprint.

Event-driven Scrum

In Scrum there is an event called Daily Scrum. Every day the team members meet for fifteen minutes to update the Sprint Backlog and each team member is supposed to answer the following questions:

• What did he/she do the previous day? How much time does he/she still need for completing the working items he/she worked on the previous day?
• What problems did he/she face while working on those working items?
• What will he/she do this day?

As mentioned before, one motivation for introducing Scrum to wedding planning was to establish a fairly even load of work amongst the sprints. Because our leisure time was not completely filled up with wedding planning there were days at which we did not have to work on any working items at all.

If my wife and I had used the event Daily Scrum, we would have said this on many days: “I did not have to work on any working items yesterday. Therefore, I did not have any problems. And there is nothing to do today either.”

So we considered Daily Scrum fairly useless for our context of wedding planning. Instead we replaced it with what we call Event-driven Scrum.

The term Event-driven is not related to Scrum events. It is inspired by a software architecture pattern[1]. In this case event means the occurrence of one of the following conditions which triggered holding an Event-driven Scrum:

• A working item was planned to be processed on the next day.
• A working item was planned to be processed on the current day.
• A working item had been processed on the previous day.

The motivation was to create an understanding that and why a working item was supposed to be worked on that particular day.

On the day after the working item had been processed my wife and I discussed whether the task corresponding to the working item was completed or whether consecutive working items had to be added to the Product Backlog and maybe also to the Sprint Backlog.

Furthermore, we discussed whether because of the knowledge gained by having completed that working items other working items had to be cancelled, re-scheduled (even postponed from the current sprint) or assigned to the current sprint.

So in an Event-driven Scrum event actually more action happens than in a Daily Scrum: It anticipates the backlog adaptation of the Sprint Review because in our context it was acceptable not just to adapt the Product Backlog but also the Sprint Backlog. Adapting the latter at the end of a sprint (when the Sprint Review occurs) would be useless in our context.

The introduction of the Event-driven Scrum of course reflects the fact that just two people participate in the entire process. If more people were involved – like in usual Scrum Teams – it would be less practical or even impossible to hold event-driven meetings.

Sprint Review

As mentioned in the Scrum Guide[2] we held a Sprint Review at the end of each sprint “to inspect the Increment”. Most of the time, adapting the Product Backlog was not necessary because that usually happened during the Event-driven Scrum.

Sprint Retrospective

As proposed in the Scrum Guide[2] my wife and I used the Sprint Retrospective to adapt the Scrum process. During the first sprints we learned what extra artefacts were helpful to be introduced which were not part of the original Scrum framework and supported the wedding planning.

As a result of a Sprint Retrospective we replaced the Daily Scrum with the Event-driven Scrum and decided to introduce adding, cancelling and postponing of working items during sprints.

Some adaptations were obvious before the first sprint. We learned very quickly while filling the Product Backlog that no extra time in each Sprint Planning event was required for estimating working items.

We also noticed that it was inevitable to share roles though this was denounced in original Scrum. Therefore, we thought about reducing conflict potential caused by sharing roles before implementing the Scrum framework.