What comes handy while thinking about how to handle a particular project? Methodologies. There is a big variety of methodologies that can be considered as a way to go and can be used as a backbone of a good, solid process.

What methodology suits a small project best?

For the purpose of managing small projects in Codete we use Scrum-ban. Scrum-ban is an agile project management methodology. It is a mix of Scrum and Kanban with aspects of both methodologies put together. As well as in Scrum, Scrum-ban process is characterized by a release taking place periodically (in Scrum-ban it happens always at the end of each iteration). From Kanban it takes lean concepts in order to ensure that, once tasks are started, they are finished as quickly as possible. Distinguishing characteristic of Scrumban is the use of a Feature freeze which means that only the features that the team already has for development can still be worked on and no additional features can be added, a Triage process to move tasks that cannot be finished in the current iteration into the next one, and a Stabilization period to ensure that the features from the current iteration are all completed and thoroughly tested before the release. Each of those parts of process will be discussed in this article series.

Work iterations

In Scrum-ban teamwork is organized in small iterations and monitored with the help of a visual board – for example Trello board. It is recommended not to have iterations exceeding two weeks span. They are usually set for one week period. To bring everyone up to date on the information that is vital for the project, each day at the same time, the team holds Daily meetings.

Each iteration starts with the Planning meeting, where the tasks for the current iteration are scheduled and checked if they are appropriately prioritised and prepared in a way that makes them clear and executable for teams once they enter iterations. After that, the development part starts. It should not take longer than 60% of the whole iteration time. After the tasks are finished, developers prepare beta application so the Client can see the results of their work.

40% of the iteration time should be dedicated to stabilize the iteration. During this process the development team fix bugs and make adjustments to the latest version of the application after the Client tests the application. If the scheduled time is not enough to fix the issues, it should be discussed on on the nearest Planning meeting. In such case it should be considered to move those issues to the next iteration with the highest priority to prevent a technological debt. If the time is sufficient and the team has very few issues to fix, they can start working on some features included in the next iteration on a separate branch.

Finally, the iteration ends with a stable version that can be released. In addition to this at the end of every iteration the team can revise the past iteration and discuss about potential improvements to make the progress of the project better on the meeting called Process improvement.

Below you can find some more detailed information about particular stages/phases of work iteration.

Small Project Management: sequence diagram

Development phase

After the Planning meeting, when the tasks for the current iteration have been scheduled, developers and testers can start performing requirements analysis. This moment is good for a developer or a graphic designer to ask questions, talk with the Client and collect all the necessary information about a task. When the analysis is done the owner of the task is ready to begin with implementation stage.

The implementation stage is intended for a developer or a graphic designer to implement a new feature, write unit tests, fix bugs, update screen design or prepare documentation.

After the owner of the task finishes his work, he needs to ask another fellow developer or a graphic designer to review his work. During development phase the review could be splitted into two parts:

  1. Acceptance review reduces the overall duration of the project, because in the early stage of feature implementation or screen design preparation, the one side is able to verify if everything looks and works as the other side expects.
  2. Code review is intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers’ skills. Code review is often known as a peer review of source code and should be performed by another developer from the team. After the review is done, it is time for alpha testing.A tester should write and perform functional tests, taking into account functional assumptions of the project.

Feature freeze

Feature freeze is used when the end of the development phase for the current iteration is approaching. It means that only the features that the team already has for development can still be worked on and no additional features can be added.


Triage is the process of determining which tasks the team can complete by the end of the development phase, and then moving the other tasks out of the iteration. It takes place right after Feature freeze. This guarantees that the team can focus on finishing important features before the project deadline and forget the less important ones.

Stabilization phase

Stabilization phase is the next phase after the Development. It starts right after the Client receives a beta version of the application. Beta version is created based on the latest alpha version of the application, but it is still considered as an unstable version. This is the goal of this phase – to produce a stable version at the end. Stabilization period usually takes 40% of an iteration time. During this period the Client tests the application and reports issues which he found. Development team fixes the issues and then prepare a new beta version which is send to the Client once again. The process repeats until the Client states the recent beta version has no issues and the features from the current iteration are all completed. Stabilization is one of the main differences between Scrum and Scrum-ban processes. Not only does it improve on-time delivery of releases, it reduces the temptation to rush through the features with inadequate testing.


This is the last phase of work iteration which follows the Stabilization period. When all features planned for the iteration are completed and thoroughly tested, the latest beta version of the application is considered to be a stable version and it is ready to be delivered or provided to the customer.


Each project should follow some kind of process, based on chosen methodology. We are suggesting Scrum-ban as our main choice, especially due to it’s flexibility and efficiency in delivering the projects. Usually it takes some time to introduce the process, but after the team understands why it should be done in such a way, it comes naturally and becomes quite easy to follow.



This article was created by Paweł Kowalczyk and Paweł Dyrek.

iOS Software Engineer

A software engineer over the last decade, crafting iOS apps since iPhone OS 3.0. Beloved in Swift, cutting teeth on Objective-C, currently learning Xamarin and C#. Hungry for new challenges and always eager to explore new things. Findable on <a href="https://twitter.com/pm_kowal"> Twitter</a>, <a href="https://pl.linkedin.com/in/pawelkowalczyk1985">LinkedIn</a> and <a href="https://github.com/pmkowal">GitHub</a> as well as on <a href="https://careers.stackoverflow.com/kowal">Stack Overflow</a> helping fellow developers. A technical writer, occasional coach and speaker. Privately happy husband and father with severe addiction to music and healthy lifestyle.

Project Manager

Director of Technology at Codete with years-long experience in building international projects using state-of-the-art technologies for both startups and enterprises. Experienced programmer, a fan of technology, and an enthusiast of Agile methodologies.