Development Philosophy

Introduction

Starting with 2015 we're going to use a Scrum based development philosophy. Our main plan is to produce more iterations per year to have a better progress instead of having big refactorings and per year releases. Our Soft-Scrum helps us to achieve that.

The following rules and statements are oblige with the start of the Sprint 39. Sprint 38 is the start sprint to prepare the base for the future sprints and does not follow all of this statements.

As developer I agree to fulfill the following statements in my development process on CWT

• BlackCat
• JakeSamiRulz

Bug-Tickets and User Stories

There will be two types of tickets from now on. Bug tickets and user stories. A bug ticket is ticket that describes a bug that has to be fixed. A user story is an improvement or new feature for the game. Normally a Sprint will be a collection of user stories that has to be realized. This will be called the Sprint Backlog. A new label, InProgress, will be used to mark stories from the backlog as in progress. The code for a ticket will be committed only when all tasks of acceptance criteria are completed. Stories that aren't ready at the sprint end will be shipped to the next sprint.

Stories has an additional special label. The story points. Unlike scrum we want to use story points to show the size of a story. Story points does not mirror the amount of days or time we need to realize it. It shows the size of a story in comparison to other stories. E.g. a story with the 1 point is a lot smaller and probably easier to realize than a story with 5 points. In the end this enables us to guess the complexity of a story and (the important one) to guess how much story points we can realize in a sprint. The last statement will be better with later sprints. Furthermore story points may show that a story is far too big for one sprint and has to be splitted into smaller tasks.

Pause

Following the same status as inProgress, this label is used to hold issues that a developer wants to work on, but is unable to work on at the moment. Therefore, it keeps other developers from working on it and doing double work. Developers are recommended to use the "Assigned To" tab to let developers know who initiated the pause and\or who is currently working on the issues. This system is used for bugs, information, and user "feature idea" stories.

Definition of Ready

The DoR describes the acceptance criteria that must be fulfilled to create a user story for a sprint. if a story does not fulfill all criteria then it has to be moved into the development backlog.

1. The ticket has acceptance criteria points
2. The story assignee understands the story and it's criterias
3. The story has a story points label

Definition of Done

The DoD defines the acceptance criteria that has to be fulfilled to set a story from Open/InProgress to the state Closed.

1. All acceptance criterias of the story are realized
2. The changes of the code is committed
3. There is inline (e.g. java doc or comments) documentation in new code
4. If the story introduces a new game feature then a test is defined in the test plan
5. The code fulfills the ideas of the CCD-Red Grade

Sprints

This introduces some new things. The first thing is the Sprint. Normally a sprints is a collection of tasks that will be done in a time window. At the end of the time window you will get a runnable version. This time window is normally from 1 to 4 weeks. As you know CWT is our hobby project and we cannot spend every minute of our lives. Because of that our sprints have a time frame of 3 months. This means we want to release four releases of CWT per year.

In this three months we're going to take two months for developing and one month for testing. After that we release the result.