Part 5: The definition of “Done” and the conclusion

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 fifth and final out of 5 parts. In this part I will define our definition of “Done”. Finally, I will discuss whether my wife and I achieved our goals by using Scrum for wedding planning.These are the other parts of this blog:

• Part 1: Motivation and the context of wedding planning
• Part 2: Roles
• Part 3: Artefacts
• Part 4: Events

The definition of “Done”

One major difference in the context of wedding planning is the lack of a shippable product after each sprint. In fact, the product created here is an event which is only “shippable” if all working items have been finished. It is not possible to present a shippable product at the end of each sprint with a subset of done working items (see The Increment in Events).

This requires re-thinking the definition of “Done” in this special context.

In our case a working item was considered done if it did not have to be touched again. This was the case if one of these conditions was true:

• The task corresponding to the working item had been completed (e. g. the wedding cake had been ordered).
• The working item had been cancelled because we had decided not to put it into practice anymore.
• The working item had been completed. However, its completion led to consecutive working items which had to be implemented in order to complete the entire task. After these consecutive working items had been added to the Product Backlog the initial working item was considered to be done.

Conclusion

When my wife and I decided to introduce the Scrum framework in order to plan our wedding we wanted to achieve the following goals:

• an (almost) even load during the entire organizing process
• a precise overview of all working items:
  • their current state (untouched, in process, completed)
  • their dependencies
  • potential deadlines for working items
• avoiding the occurrence of obvious organizational shortcomings during the wedding

Goal 1: Even distribution of workload amongst the sprints

Until the wedding celebration, we had completed all 158 working items we had entered into the Product Backlog within 13 sprints. The number of working items completed per sprint varied between 5 and 29. The average number of working items per sprint was 12.15.

The expected standard deviation for a discrete uniform distribution for 13 elements and an expected value of 12.15 is 6.74, the empirical standard deviation amongst the sprints is 7.01. So the empirical distribution is very close to the uniform distribution which suggests that the first goal has been achieved from the statistical perspective.

With the exception of sprint 04/2016, during which 29 working items had to be completed, the number of working items were in a range between 5 and 18 and turned out to be quite maintainable, especially because the number of items completed did not reflect the time required for completing them.

Some working items in the last three sprints for instance were completed within one hour. Though the number of working items completed in those sprints was above average the time spent on completing them was not (except of sprint 04/2016).

The only sprint which turned out to be real hard work was sprint 04/2016 (especially its third week), because a few working items caused unexpected consecutive working items. In general, consecutive working items were not a problem because they could be easily placed into future sprints.

Unfortunately, this was hardly possible for the consecutive working items which occurred during sprint 04/2016. There was only one future sprint left (05/2016) which from the temporal perspective was just a half sprint (we married in the middle of May). So we were forced to complete most of those working items in sprint 04/2016 regardless of the working items already planned there.

Apart from that the load per sprint was acceptable.

Goal 2: Precise overview of all working items

During the planning process I felt very confident that I knew what was going on though this occasion was the first time that I had to deal with wedding planning.

Whenever new tasks emerged (which happened quite often at the beginning of the organizing process because there were many things we did not consider) I discussed those tasks with my wife immediately and directly afterwards inserted them into the Product Backlog. Sometimes we decided to process the working item corresponding to the task in the current sprint, so I also updated the Sprint Backlog. This ensured that ideas and requirements did not get lost.

Because every working item in the Product Backlog had at least a proposed schedule (if not a concrete one because it was planned for the current sprint) there was at least a rough idea when to complete it. Because part of Product Backlog grooming was to evenly distribute the remaining working items we ensured that we were not surprised by an unmaintainable number of incomplete or even unplanned working items by the end of the organizing process.

Furthermore, because of the look-ahead facility of our Sprint Backlog and the planned schedule in the Product Backlog the workload of the future sprints was transparent to us. Therefore, it was fairly easy for us to decide whether postponing working items was possible or not.

Goal 3: Avoiding the occurrence of organizational shortcomings during the wedding

Fortunately, none of those shortcomings occurred during the wedding. However, this was not coincidence, but the logical result of our process.

During the stakeholders phase my wife and I planned thoroughly the general tasks for the wedding (e. g. the wedding ceremony, the location, photographer and so on). In the Product Owner phase I identified the missing tasks from a helpful guide¹ and added the working items for all those tasks to the Product Backlog.

Whenever my wife or I identified a new task I (almost) immediately broke it down into working items, prioritized them and placed them into the Product Backlog observing the workload of each sprint. Therefore, those tasks could not get lost.

General aspects of the planning process

Scrum enabled us to plan with great flexibility. We were able to react quickly to new requirements and sometimes even circumstances. For instance, in sprint 09/2015 we learned that we had to postpone our wedding by one week because the registry office would be closed on our planned wedding day (it was not possible to make an earlier reservation at the registry office). At that time the photographer and location had already been booked forcing us to change those reservations. This was fairly easy within the Scrum process.

The Scrum process itself was very smooth, too, though my wife was not familiar with the Scrum framework. However, the guidance of a Scrum Master (in this case one of the people involved in planning, but it is also possible to employ an external Scrum Master) and the native approach to teach her Scrum enabled her to cope with this framework.

The planning process in general went well, too, especially though neither my wife nor I had ever been involved in wedding planning before.

During the planning process 6 out of 158 working items (3.8%) were cancelled because of changing requirements. No working item at all had to be cancelled because of lack of time. We did not even get into the situation to consider cancelling a working item due to lack of time.

Maybe I should have provided more information to the Product Backlog for evaluating the planning process. I should have tracked the following information:

• the duration spent on completing each working item
• the time each working item was added to the Product Backlog
• the time a working item was last modified

At the time, I got the idea to track that information I could not provide it anymore for most of the working items. So I discarded the idea.

The wedding celebration went very well. Of course, some things did not happen according to our planning. But this was not the case due to lack of organization but because of other circumstances (the weather e.g. forced us to do some spontaneous adaptations to the schedule of the wedding celebration). Apart from that the wedding took course as my wife and I had expected. It was a lovely personal way of celebrating it.

Theoretically speaking, if I would have to organize my wedding again, I would do it exactly the same way as we did, not just the way we celebrated it but also and especially the way we organized it.

The fact, that a wedding planning rookie like me manages to organize his first (and hopefully only) wedding without pitfalls with the help of Scrum, proves that this framework is suitable for supporting contexts beyond the scope of software development.