In the last years of higher education, students need to learn to work on a project base. “The business is calling for project-oriented development, for hard & soft skills”. So a business situation is simulated. Students are divided into teams and have to select a subject from a list (in our case this list has been made up by another group of students – those who will perform the client role.)
In our case (the case of ICT AP school), the client role is performed by our Finnish partner school OAMK – school of engineering Oulu Finland, which makes this a great example of an international business case simulation. Communication, distribution of workload and effort are essential for the succeeding of the project. These parameters are difficult to assess, given that one teacher has to evaluate several teams.

Project teams need to be self-organized and self-evaluating. To implement this kind of self-direction, Agile project management is used.

Agile is a management system based on the constant repetition of project processes. In case of software development, this means that the cycle of specification, design, implementation, testing and deployment need to be re-iterated on a regular base.
Software specification means defining functionalities and restrictions of the system. You assess whether it is technically and financially feasible to build the system. Stakeholders of the system can express their expectations. This leads to the requirements specifications, aka the defining of functionality.
After the specifications phase, specifications are converted into an executable system. This is the design and implementation phase.
In the validation phase, clients can judge whether the product meets the needs and requirements of the customer. When this turns out positively, the development team need to consider if there are new requirements or changes the client wants.
In Agile project management, all these phases are continued iteratively during the project cycle. In order to do so, the project is split up into smaller components, of which the results are measurable (successful or not), and of which timing can more easily be estimated.

To initiate the project, the client drafts a blueprint of the requirements of the product and he writes user stories about it. User stories are short descriptions of what the wants. No detailed documentation which could cause hair-splitting discussions between clients and analysts in an early stage, but short texts that make it clear what a user should be able to do with the software. When a project starts of, knowledge about the product is still limited. The advantage of working with user stories is that both teams (clients & developers) constantly think about new ideas, and this often results in a new twist in the final product.


During a sprint kick off the team as whole – clients and developers – choose which user stories will first be implemented. Sprint is a terminology used to indicate a set period of time during which specific work has to be completed and made ready for review and during which the sequence cycle of specification, implementation, testing and installation is completed. Agile developing is structured as a chain of sprints.
Imagine a project which takes 5 months, with every two weeks a new sprint. They determine the sequence and timing themselves: the teams are self-directive. Client and developer analyze the selected user stories. The developer gains a greater sense of responsibility, because of his commitment in the total process, but also because of his increasing knowledge on the matter; he is constantly developing, testing and adjusting the product.

From now on, the cooperation with the developing team starts. A first skype meeting is organized. On the agenda of this meeting is a discussion of the user stories and decision about the technology to be used. Agreements on the first sprint meeting are made.

Check out previous articles of IPD on our blog: