Kata 1: Conference scheduler

Practise discovering responsibilities and collaborations while implementing a small scheduling workflow.

The exercise is intentionally manual. The organiser already knows which talk they want to schedule, which room they want to use, and which time they want. The system accepts or rejects that request according to the business rules.

This kata is not about finding an optimal schedule. It is about noticing how responsibility placement changes as more scheduling rules appear.

A one-day software conference needs a simple scheduling tool.

The organiser builds the public agenda by placing talks into rooms at specific times. Attendees use that agenda to know what happens, where it happens, and when it happens.

The system must protect the agenda from impossible schedules. A conference schedule is not valid just because talks have titles and times. It must also respect rooms, speakers, availability, and suitability.

Build the behaviour needed to schedule talks into rooms and show the public agenda.

A talk has:

• A title

• A speaker

• An expected number of attendees

• Optional requirements, such as needing a projector

A room has:

• A name

• A capacity

• Optional capabilities, such as having a projector

A speaker may be unavailable at specific times.

Use this vocabulary to describe the business problem. It is not a proposed implementation model.

• Conference

• Public agenda

• Talk

• Speaker

• Room

• Time

• Capacity

• Capability

• Scheduling request

• Move request

• Rejected request

• The organiser schedules one talk at a time.

• Time is represented using fixed labels such as 09:00, 10:00, and 11:00.

• A room can host at most one talk at the same time.

• A speaker can give at most one talk at the same time.

• A room is suitable only when it has enough capacity and the required capabilities.

• A rejected scheduling request must not change the existing agenda.

• A rejected move request must not change the existing agenda.

Before moving to the next scenario:

• Is the behaviour covered by a failing test first?

• Is the expected outcome observable from outside the implementation?

• Are previous scenarios still passing?

• Does the test describe business behaviour rather than internal structure?

• Did the last change introduce duplication worth refactoring?

• Can the current design be explained without mentioning a framework, database, or user interface?

⚠️ This kata has counterexample that you do not have to follow, they are meant to force you, to think about the sad path

The public agenda is the visible result of the scheduling work.

If nothing has been scheduled, the agenda is empty. If talks have been scheduled, the agenda shows those talks. The agenda should be useful for attendees, so talks must be shown in chronological order, regardless of the order in which the organiser scheduled them.

This rule does not say how the schedule is stored. It only says what the conference must be able to show.

This rule gives the kata its first observable behaviour.

Before rejecting invalid schedules, checking room conflicts, or moving talks, the system must be able to show what has already been accepted into the conference schedule.

The agenda is not a technical report. It is what attendees would read to know what happens during the day.

The organiser schedules “Refactoring legacy code” at 09:00.

When the public agenda is requested, the talk appears at 09:00.

A new conference has no scheduled talks.

When the public agenda is requested, it should not invent placeholder talks, default sessions, or sample data. It should be empty.

This rule starts with visibility. The first behaviour is not validation. The first behaviour is showing what the business has accepted so far.

Later rules will make it harder for something to become accepted into the agenda. For now, the goal is simply to make accepted talks visible.

A conference has just been created and no talk has been placed yet.

Scenario: Show an empty agenda
  Given a conference with no scheduled talks
  When the public agenda is requested
  Then the agenda is empty

The organiser places one talk in a room that can host it.

Scenario: Schedule one talk
  Given Room A can host "Refactoring legacy code" at 09:00
  When the organiser schedules "Refactoring legacy code" in Room A at 09:00
  Then "Refactoring legacy code" appears in the public agenda at 09:00

The public agenda should show more than one scheduled talk.

Scenario: Show several scheduled talks
  Given 3 talks are scheduled
  When the public agenda is requested
  Then the agenda shows 3 talks

Talks may be scheduled in any order, but attendees need to read the agenda by time.

Scenario: Show scheduled talks in chronological order
  Given talks are scheduled at 11:00, 09:00, and 10:00
  When the public agenda is requested
  Then the talks are shown as 09:00, 10:00, and 11:00

A room can only host one talk at a given time.

Two talks may happen at the same time in the conference, but not in the same room. This is about protecting a physical constraint. A room cannot contain two independent sessions at the same time.

The agenda must be realistic.

A schedule that places two talks in Room A at 09:00 is not a valid conference schedule, even if both talks are otherwise valid.

This rule introduces the difference between:

A talk can exist.

and:

A talk can be placed in this room at this time.

Room A hosts “Refactoring legacy code” at 09:00.

Room B hosts “Testing microservices” at 09:00.

This is allowed because the talks use different rooms.

Room A already hosts “Refactoring legacy code” at 09:00.

The organiser then tries to schedule “Testing microservices” in Room A at 09:00.

The request must be rejected.

The system now has to preserve a valid agenda, not only record requested talks.

A rejected request must not replace or remove the talk that was already scheduled. Rejection is not just a return value or an error. It also means the previous valid schedule remains valid.

Two different rooms can host two talks at the same time.

Scenario: Schedule two talks in different rooms at the same time
  Given Room A is available at 09:00
  And Room B is available at 09:00
  When two talks are scheduled at 09:00 in different rooms
  Then both talks appear in the public agenda

A room already used at 09:00 cannot host another talk at 09:00.

Scenario: Reject two talks in the same room at the same time
  Given Room A already has a talk at 09:00
  When another talk is scheduled in Room A at 09:00
  Then the scheduling request is rejected

A rejected conflicting request must not remove or replace the original scheduled talk.

Scenario: Keep the original talk after a room conflict
  Given "Refactoring legacy code" is scheduled in Room A at 09:00
  When "Testing microservices" is scheduled in Room A at 09:00
  Then "Refactoring legacy code" remains scheduled in Room A at 09:00

A speaker can only give one talk at a given time.

Even if two different rooms are available, the same person cannot speak in both rooms at once.

This rule is different from room conflict. A room conflict is about a place. A speaker conflict is about a person.

A schedule can look valid from the room perspective and still be impossible for a speaker.

The conference needs a schedule that works for both attendees and speakers. A schedule that asks Alice to give two talks at 09:00 is not valid, even when those talks are in different rooms.

Alice gives a talk at 09:00.

Bob gives another talk at 09:00.

This is allowed because they are different speakers.

Alice is already giving a talk at 09:00.

The organiser tries to schedule another talk by Alice at 09:00.

The request must be rejected.

The system now has more than one kind of conflict.

A talk can be rejected because of the room, because of the speaker, or because the speaker is unavailable. The kata starts to move from simple storage toward business rules that interact.

Different speakers can give different talks at the same time.

Scenario: Schedule two talks by different speakers at the same time
  Given Alice is available at 09:00
  And Bob is available at 09:00
  When their talks are scheduled at 09:00
  Then both talks appear in the public agenda

Alice cannot give two talks at 09:00.

Scenario: Reject two talks by the same speaker at the same time
  Given Alice is already speaking at 09:00
  When another talk by Alice is scheduled at 09:00
  Then the scheduling request is rejected

A speaker may be unavailable even when they are not already scheduled for another talk.

Scenario: Reject a talk when the speaker is unavailable
  Given Alice is unavailable at 09:00
  When Alice's talk is scheduled at 09:00
  Then the scheduling request is rejected

A room being free is not enough. The room must also be appropriate for the talk.

A talk may need enough seats for expected attendees. A talk may also need a capability such as a projector. If the room does not satisfy those needs, the talk cannot be placed there.

A schedule should not only avoid conflicts. It should also make sense operationally.

A room with 30 seats cannot host a talk expecting 40 people. A talk that requires a projector cannot be placed in a room without one.

A room has capacity 40.

A talk expects 40 attendees.

The room is suitable by capacity.

A room has capacity 39.

A talk expects 40 attendees.

The request must be rejected because the room is too small.

The idea of “valid scheduling” becomes richer.

A request can now be rejected even when the room is free and the speaker is available. Availability and suitability are not the same thing.

A room with capacity 40 can host a talk expecting 40 attendees.

Scenario: Schedule a talk when the room has exactly enough capacity
  Given Room A has capacity 40
  When a talk for 40 attendees is scheduled in Room A
  Then the talk appears in the public agenda

A room with capacity 39 cannot host a talk expecting 40 attendees.

** Keep in mind that this is not probably how you would implemented in real life, because you may reject the attendee if you instead of the talk or have other kind of solution for this, this is only for the kata purpose.

Scenario: Reject a talk when the room is too small
  Given Room A has capacity 39
  When a talk for 40 attendees is scheduled in Room A
  Then the scheduling request is rejected

A talk requiring a projector can be scheduled in a room with a projector.

Scenario: Schedule a talk when the room has the required capability
  Given Room A has a projector
  When a talk requiring a projector is scheduled in Room A
  Then the talk appears in the public agenda

A talk requiring a projector cannot be scheduled in a room without one.

Scenario: Reject a talk when the room lacks the required capability
  Given Room A has no projector
  When a talk requiring a projector is scheduled in Room A
  Then the scheduling request is rejected

The organiser can move an already scheduled talk to another room or time, but the move must obey the same business rules as a new scheduling request.

If the target room and time are valid, the talk moves. If the target is invalid, the move is rejected and the original schedule remains unchanged.

Real schedules change.

A speaker may request another time, a room may become unavailable, or the organiser may want to improve the agenda.

But changing a schedule is risky. A failed move should not leave the agenda half-changed. The system must protect the current valid agenda while trying to apply the requested change.

“Refactoring legacy code” is scheduled at 09:00.

The organiser moves it to an available slot at 10:00.

The agenda now shows it at 10:00.

“Refactoring legacy code” is scheduled in Room A at 09:00.

The organiser tries to move it to Room B at 10:00, but Room B is already occupied at 10:00.

The move is rejected and the talk remains in Room A at 09:00.

The kata now asks for safe change, not only initial scheduling.

The system must protect the current valid schedule when a requested change cannot be accepted.

A scheduled talk can be moved to another valid time.

Scenario: Move a talk to an available slot
  Given "Refactoring legacy code" is scheduled at 09:00
  When the organiser moves it to 10:00
  Then "Refactoring legacy code" appears in the public agenda at 10:00

After a successful move, another talk can use the original room and time.

Scenario: Release the original slot after moving a talk
  Given "Refactoring legacy code" is scheduled in Room A at 09:00
  When the organiser moves it to Room B at 10:00
  Then another talk can be scheduled in Room A at 09:00

A talk cannot be moved into a room and time that are already occupied.

Scenario: Reject a move that creates a room conflict
  Given Room A already has a talk at 10:00
  When another talk is moved to Room A at 10:00
  Then the move request is rejected

A rejected move must not remove the original scheduled talk.

Scenario: Keep the original schedule after a rejected move
  Given "Refactoring legacy code" is scheduled in Room A at 09:00
  When it is moved to an occupied room at 10:00
  Then "Refactoring legacy code" remains scheduled in Room A at 09:00