Behind the scenes: Scrum process at Finfox
More than just a buzzword – the Scrum method has become the state of the art in agile software development. We take a look behind the scenes at Finfox and show how we use and benefit from the Scrum process in the development of our mobile applications FinfoxAdvice and FinfoxTouch. But also where and why we deliberately deviate from the theoretical guidelines in certain areas.
Maintenance of the backlog
The backlog contains all work orders to be implemented in the near or distant future. We have divided the backlog into two parts. A first part contains the technical requirements, the so-called user stories, which are the responsibility of the business analysts and the respective product owner (i.e., the internal client) and are prioritized by them. The second part contains technical stories, such as version upgrades or code quality improvements; in other words, tasks that are identified and maintained by the development team.
The Scrum Board provides information at any time about the current status of processing: Which tasks are pending, in progress or already completed? We maintain the board purely electronically using a tool which is well established in the industry. We do not have a physical board with paper notes per story. Since some of the work is done in the home office nowadays, the benefits of an electronic board are obvious.
Organization in sprints
Planning the development work in the form of sprints (iterations) is very valuable to us, as the team deals with the detailed planning in a structured manner at regular intervals and consciously commits to a specific schedule.
At Finfox, a sprint is rather short, usually two or in exceptional cases three weeks. According to Scrum specifications, 2 to 4 weeks are possible. We prefer the short time intervals, because we prefer to hold planning meetings more often but keep them shorter. In addition, we can react very quickly to customer requests or, if necessary, adjust the prioritization at short notice when planning the next sprint.
In case of vacation absences or public holidays, the sprints can sometimes take a little longer. We strive to keep the total workload for the team more or less constant per sprint.
Sprint Planning Meeting
The Sprint Planning Meeting is used to define the “content” of a sprint, i.e. the detailed planning for the next 2 to 3 weeks. We conduct this meeting pretty much according to the Scrum textbook. The product owner presents the stories, the team then estimates the implementation effort for each story in “story points” and plans the stories in accordance with the team capacity. For us, to keep things simple, one story point (i.e. the abstract unit of measurement for complexity in Scrum) corresponds to one person-day of work. We distribute the stories as precisely as possible to the individual team members already in the planning meeting to ensure that all are utilized according to their respective core competencies and workloads.
In the Daily Scrum Meeting, every day at the same time for about 15 minutes, the members of the development team discuss the progress of the work and open questions. Product owners and business analysts do not participate. If necessary, the Daily Scrum Meeting can result in requests to the product owner or in points that need to be further discussed bilaterally in the development team.
Sprint Review Meeting
The Sprint Review Meeting usually takes place at the end of a sprint and serves to present the work results to the team and the internal clients. In this meeting, we deviate strongly from the Scrum guidelines, because we do not hold it only once per sprint but weekly and independent of the sprint rhythm. Strictly speaking, this meeting is not a sprint review meeting in the sense of Scrum. Rather, we present completed stories, discuss open questions or possible solutions to new requirements, the implementation of which is not yet immediately planned.
A big advantage of the weekly meeting for us is that completed stories can be presented to the internal clients much faster than if this would only happen at the end of the sprint. If necessary, corrections can usually be made during the current sprint.
A product increment is a software package that is finalized in the classic Scrum process at the end of the sprint and contains all implemented requirements. However, we do not complete and deliver such an increment at the end of a sprint. Instead, testable deployment packages are typically built once a week or as needed, regardless of the sprint cycle.
Retrospective meetings are a must for us. However, we hold these meetings only every few months and not at the end of each sprint as is usual. We consider this meeting format to be valuable because by jointly taking a look back at the past sprints we can constantly optimize our cooperation and develop as a team. The meetings are always set up differently and organized and moderated alternately by the members of the development team.
«Scrum means to us: clear and transparent work orders, reliable detailed planning and quick feedback on the implemented tasks. This significantly increases the efficiency and quality of our work. The regular scrum meetings are also extremely beneficial for internal communication and the team spirit.»
Front End Developer at Finfox
When developing the software for our mobile applications FinfoxAdvice and FinfoxTouch, we lean heavily on the Scrum method, even if it’s not Scrum in its purest form. We use those elements that bring us added value and leave those aspects out that would generate more effort than benefit within our individual setup.
Overall, the applied Scrum process model is appreciated by the development team as very valuable and advantageous.