How eVolpe works in Scrum?

Creating a Product Backlog

The actual activities of Scrum start right after a stage of consultancy, selection of the system and crucial business arrangements. First, they turn into some analytical operations. At eVolpe, we suggest taking advantage of two types of workshops: System Overview and Product Discovery. These are highly creative meetings that allow you to look at customer relationships managing from both a narrow and a wide perspective. Worth emphasizing is that they require an advanced level of commitment from the customer. During such workshops, to better visualize the issues and to take advantage of creative techniques, we use a variety of colored post-its, pens, whiteboards or antistatic foils.

A result of System Overview and Product Discovery workshops is Product Backlog, mainly in a form of User Stories. A Product Backlog is always prepared by an eVolpe representative who plays the role of proxy Product Owner (a business link between the customer and development team). Product Backlog then needs to be prioritized. That procedure is carried out jointly by proxy Product Owner and the Product Owner (customer’s representative and the person responsible for decision making and shaping the vision of the software together with development team).

In some cases, on the basis of Product Backlog, an estimation of costs and components can be done. It helps to obtain the order of the Sprints and the size of the whole project before the development starts. This approach is used most often when the client is interested in determining the budget of the project. However, it has to be noted that SCRUM allows and even supports changes during development! Having that in mind, any financial estimate is mainly opinionative.

During Sprints

The implementation of a Scrum project happens in 2-weeks-long iterations. This means that after each such period (Sprint) a new functionality or change or improvement needs to be introduced. Each iteration begins with a meeting called Sprint Planning. The purpose of that is to set the goal for the upcoming Sprint (an overriding value that has to be obtained). The second part of Sprint Planning requires careful scheduling so that the completed software meet the definition of DONE.

It is extremely important, that every working day is followed by a brief, up to 15 minutes Daily Stand-up. Such a meeting takes place at eVolpe by our Scrum whiteboards (in parallel we are also using Redmine – custom project management system). Each time our development team meets, we do an inspection of our own progress. It is also a great opportunity to adapt the plan to the actual conditions. We also determine what was accomplished, what is the plan for the next day and whether there have been any difficulties.

During the Sprint, there are also meetings called Refinement. They are dedicated to the new requirements that arise from the client. Such matters are available in the Product Backlog and may be selected for execution during the forthcoming Sprint.

What does each Sprint end with?

At the end of each Sprint, we meet with the customer (usually remotely) during an appointment called Sprint Review. The team then gives out the software increment to a customer, then briefly presents what was done. It is also a good time to discuss new requirements (that could have been inspired by the current shape of the product), changes and expectations for the next Sprint. This also needs to be followed by a regular inspection of was already done as well as by adaptation to the new requirements.

After each Sprint, it is possible to install packages that create increments in the customer’s production environment. Of course, not every Sprint has to end with such a release. It is fully dependent on customer’s decision. The client has the opportunity to become acquainted with the new functionalities in the test environment prepared for him as well. On this basis, a customer is able to give out the final acceptance to the outcome of a specific Sprint.

The last meeting with the Scrum Team, proxy Product Owner, Developer Team, and Scrum Master (responsible for the process) is Sprint Retrospective. A Retrospective is a great opportunity to inspect the way we work as a team, as well as the interpersonal relationships between us. We discuss what we have achieved, what we are proud of and what we must work on to become more effective and mature.

Each project can consist of many consecutive Sprints. Usually, it is from several to even several dozen such iterations. Once the customer has determined that the product is done, we move on to the maintenance mode determined by the service contract.