[FEATURE]: Add random events on TODO list

[warrenfung1]

The game may add some random events on TODO list, enforcing some tasks on the TODO list that must be purged to simulate case like short notice and high priority case:

[DelphineWongPolyU]

Addressing Kanban Methodology Integrity with Random Event Integration

It's important to consider the core principles of Kanban when integrating new features. The "To-Do" column traditionally represents items that have been planned and are ready for development. Introducing random events directly into this column could potentially conflict with the Kanban methodology and confuse players.

Alternative

Here are an alternative to maintain the integrity of the Kanban system while incorporating the suggested feature: Event Queue: Create a separate queue for random events that sits alongside the Kanban board. Players can view this queue as external factors that will impact their workflow but aren't part of the standard flow until they are manually moved to the "To-Do" column.

If we need to move forward with this idea, we would also need to flesh out several details: Frequency and Timing: Could you propose a tentative frequency for these events? Any ideas for triggers or patterns? Suggestion: Implement a configurable setting for event frequency to accommodate different player preferences.

Variety of Events: What kinds of random events do you have in mind? Please share some examples. Suggestion: Start with a basic set of random events and expand over time based on player feedback.

[failee711]

I don't think adding random events on TODO list is a good idea.

1. Newly added feature enhancement/bug fixing should be added to BACKLOG, instead of TODO list. For example, the defeats in the game, which were in red, were added to BACKLOG also, even if they were very urgent. It should be the principles. Therefore, adding random events to TODO list is not suitable.

2. The game has a ranking right after finishing the game. If we add random events in the game, it is not fair to make a ranking. Instead, if we need to make enhancements with this idea, we should think more about how to handle the ranking issue. Suggest: We can make two modes of the game. One is normal mode, which does not contain any random events. One is random mode, which contains random events.

[yihanghang]

In my opinion, adding random task events to the todo list is not a very reasonable approach. Here are a few reasons:

Focus and priority: Todo lists are usually used to record and plan specific tasks and goals that need to be completed in software design work. Adding random task events may distract the team's attention and energy and reduce work concentration. Additionally, if random task events are added that are not high priority or not related to the design goals, it may prevent the team from completing core tasks on time.

Chaos and management difficulties: Randomly adding task events may make the todo list confusing and unclear, making it difficult for the team to effectively manage and track the progress and priority of tasks. This can lead to difficulties in communication and collaboration within the team, affecting the overall software design process.

Risk and efficiency: Random task events may involve risks and unknown factors, which may increase uncertainty in the software design process and reduce work efficiency. During the software design phase, tasks need to be carefully planned and managed to ensure steady progress as planned.

To sum up, I think the better approach is to still add it to the backlog list, and then put it into the todo list after team consultation to ensure that software development work continues to proceed efficiently.

[warrenfung1]

Thanks for taking the time to provide feedback on the incorporation of random events into the to-do list of the game.

The discussion around the use of 'Backlog' as a visual item to aid 'Pull systems' shed light on the complexities involved in managing development tasks.

Kanban as a visual management method, originating from lean manufacturing principles. 'Pull systems' as one of the five principles of it. Points about the 'Backlog' in making the development team focus on their Kanban board without seeing the bigger picture could be happened. Undoubtedly, selecting tasks from the backlog could be a key to success, and crucial for user satisfaction in the game. However, the ability of stakeholders such as the product owner and project sponsor to define project criteria is well acknowledged, they would be the one who seeing the bigger picture.

The suggestion to introduce a random event, such as the 'Kick off Booking function first', aligns well with the practical reality of project management. We understand that the dynamic nature of real-world cases often necessitates a balance between practicality and adhering to principles. It's a constant challenge of finding harmony between the two, and some perspective reinforces the importance of methodology aspects.

Our insightful distinction between the practical and the principle is duly noted, and it is recognized that there is no absolute right or wrong in these scenarios. The intention behind incorporating random events is indeed to mirror real-world dynamics, acknowledging the nuances that exist in day-to-day project management.

Thank you for the thoughtful feedback. The contribution is invaluable in refining the simulation game to be more reflective of the challenges faced in the software development workflow.