OUR WAY OF WORKING

New requirements placed upon our 360^e software are drawn-up in workshops that our project team holds jointly with our new clients. For instance, the background can be a special product portfolio, creating particular requirements for customer service or dispatch requirements and thus affecting 360^e. Additional profiles of needs come in directly from existing clients, who are continually further developing the software with us.

The requirements are drawn-up as a User Story. By formulating this in terms of “I would like (this), in order to …“, it becomes clear who is placing a functional requirement on the software, and why. This requirement gets more closely specified by formulating acceptance criteria. We edit the stories in such a way that implementation brings into being an additional piece of viable software, one that benefits a business accordingly.

It is our Product Owner that presents the User Stories to the development team, as the person with product responsiblity. After clarifying the subect-specialist aspects, the development team holds an Estimation Meeting, to conduct a complexity assessment on the stories, in terms of Story Points.

The stories are drawn together in our backlog, with the Product Owner allocating priority levels to them, coordinating this with the stakeholders. The stakeholders are (firstly) our clients; (secondly) our Customer Service, representing our established client-base; and (thirdly) the project team as spokespeople for the ongoing new-client projects.

The User Stories are implemented in the context of a Sprint, a process of fixed duration: at e-velopment it is precisely two weeks.

At the start of a new sprint, the most highly prioritised stories are adopted into the Sprint Backlog. In the Sprint Planning, these stories are discussed by the development team, as they jointly determine the tasks to be completed, to shape the stories into reality. By making its forecast, the development team determines the extent of the stories to be implemented in the sprint.

The software is further developed by the team working through the stories in the sprint. The overview, showing all stories being processed in the current sprint, is to be found on the respective development team’s SCRUM Board. As the sprint advances, the tasks that the stories entail are converted into action, and the progress status is visualised on the SCRUM Board. Each day at the same time, the SCRUM team convenes for its ‘Daily‘. This is where the state of the project‘s progress is communicated. Each participant answers three questions:

• What did I get done yesterday?
• What do I want to get done today?
• What obstacles do I face?

This is how the team focuses on reaching its goals; obstacles that emerge are explicitly stated. Eliminating these obstacles, or respectively enabling the team to do this, is one of the Scrum Master’s key tasks. Our Scrum Master provides support to the development team in organising itself, as well as in recognising and resolving conflicts. He makes sure that Scrum is understood and shaped into reality, and also that its practices and rules are kept.

The result of a sprint is a new release of the 360^e software. At the end of the sprint, the scrum teams sit together, including the Product Owners, so as to present the results to themselves and to the other participants, in the context of the review. As a supplement to the new release, our clients receive the Release Notes, where we present the software’s new functions.

After the review, following on from the sprint, the Retrospective takes place. This is a team meeting all about learning from the past. Participants assess what went well and what went badly. The reasons are discussed and improvement measures are agreed upon.

After each sprint, the preparation for the next sprint begins again, and the process at e-velopment resumes anew.