SCRUM & Webtown

In SCRUM we trust.

Quality

We believe, that quality in software development means the highest level

We believe that in software development, the primary meaning of quality is the perfection of compliance with the business goals, which inherently includes the clear understanding of the requirements, and the high-level development skills associated to this, as the combined result of which the software and its related resulting products emerge.

We also believe that the exact matching of requirements and solutions leads to the creation of value if it takes place at the same time, thus the only real solution is software that is delivered quickly, in good quality and free from errors.

The fact that our solutions meet all three conditions means that we follow the agile guidelines, for which we use the SCRUM framework. Our SCRUM teams are self-organizing, cross-functional, and they deliver and refine their own techniques at the same time in 1-week sprints, thus ensuring continuous improvement.

In accordance with our guidelines, our agile approach is applied not only in software production, but our entire company is being built as a flat organization, thus providing the self-organization and space required for intellectual work and evolution.

We at Webtown use the SCRUM method as follows.

Principles, rules

Events, roles and work materials are connected to each other by the rules of Scrum, which determine the relationships and interactions between them. Scrum Teams develop their own rules, the work materials and tools used in accordance with the principles and values of Scrum.

Scrum principles:

- Value-based prioritization (Product Backlog)

- Co-operation (within the Scrum Team and with stakeholders)

- Self-organization

- Empirical process monitoring (review on retrospective events, continuous monitoring of the progress towards goals (vision, sprint goal))

- Iterative development (potentially releasable product increment in every sprint)

- Time frame (time-boxed events)

SCRUM offers the following advantages

Below we have collected our experiences why we think that the use of Scrum is mutually beneficial for both our partners and our company.

Creating value

With the help of the Scrum framework, instead of delivering purely functional requirements, we deliver requirements that bear the business value defined by the Product Owner, the implementation of which is planned and carried out by the Development Team.

The efficient and direct communication between the Product Owner and the Development Team contributes greatly to the production of solutions of high technological standards and outstanding quality.

Product planning is performed based on the working software

In the course of our projects we pursue – as much as possible - to perform all activities required for the software to be ready to go live in accordance with the delivery process designed specifically for the project in the course of the sprint. In connection with this, we recommend the organization of content upload tasks as continuous activities adjusted to the content of the sprints as well, in order to avoid the accumulation of these tasks and their delaying of the product activation.

As a result of the solutions used, it is an achievable, realistic goal that an idea may be seen by the Product Owner in a finished product after a single sprint, and their decisions concerning the product may be made not based on a plan envisioned in documentation, but rather in the sight of and based on working software.

The business area may receive the portal interfaces belonging to them for business validation without delay, thus the delivery of the solution that is ideal for them in the final product can be verified and ensured even based on multiple cycles of feedback.

One of the biggest advantages of agile projects is that via product increments delivered continuously, a state of potentially going live can be reached at the end of each sprint.

Quick accommodation to changes

The regular processing of feedback and planning by sprint provides an opportunity for the Product Owner to always adjust their requirements to the current goals and user expectations.

This helps ensure that the product delivered at the end of the project contains functions that will be used by the end users and represent real business value.

With the use of Scrum, the costs of changes are significantly lower than in the case of traditional methodologies, in which all modifications are added to the originally planned costs in the form of additional expenses.

High quality

In Scrum, quality can be defined as the ability to ensure that the product or the resulting products meet the “Done” criteria, and achieve the business value required by the clients.

  • The “Done” criteria, and if necessary, the co-operation scheme are developed by the members of the Scrum Team together, and are reviewed by them continuously.
  • In order to ensure high quality, it is essential to reduce, eliminate technical debt. In favor of this, we examine source code quality with the source code quality verification software SonarQube, and complement manual testing with automated tests.
  • For the verification of the expected business value, tests performed on real users provide the most efficient solution.

Testing is present as a continuous activity, thus errors do not show up at the end of the project

The manual tests performed within the sprint are complemented with automated testing solutions, which provides the possibility to perform extensive testing regularly, for the solutions delivered in previous sprints as well. With the active participation of the stakeholders, and frequent user testing (which may even follow each sprint), errors resulting from faulty requirement analysis and planning can be detected early, thus the costs of error correction can be reduced.

The documentation prepared contains current demands and solutions

Thanks to the maintenance of the optimal level of the user story collection, the user stories always contain current demands, and the amount of user stories required for the speed of the Development Team is available.

By updating the resulting documentation products of the system in every sprint, accordance between the system descriptions and the product can be ensured.

Roles

In Scrum, 3 key roles are distinguished, which are: Development Team, Product Owner, and Scrum Master.

Product Owner

The person responsible for the maximization of the value of the product and the work performed by the Development Team, a link between the stakeholders and the Development Team.

Main tasks:

  • Identification and involvement of stakeholders, key participants.
  • Measurement and documentation of business demands and requirements.
    • Preparation and continuous control of the Product Vision.
    • Preparation and maintenance of the Product Roadmap.
    • Maintenance of the Product Backlog – preparation of user stories.
    • Measurement of non-functional demands, determination of “Done” criteria (Definition of Done).
  • Preparation of the Release Plan, prioritization of the backlog and determining the sprint goal taking the planned release deadlines into consideration.
  • Active involvement in UI/UX planning. Ensuring accordance between the user stories and the wireframe plans.
  • Communication with the stakeholders.
  • Co-operation with the Development Team.

Development Team

The Development Team is a self-organizing team, the members of which are jointly responsible for the planning of the implementation of backlog items, and the proper completion of “Done” criteria.

Main tasks:

  • They are responsible for the understanding of business demands, the planning and estimation of the solution that meets the demand best, and the completion of the product.
  • The items in the backlog are completed and presented by the team along the methodological rules.

Scrum Master

The Scrum Master is responsible for compliance with the rules of the framework, and for providing the conditions required for the Development Team to perform work efficiently.

  • They ensure that the order of the acceptance/approval of deliverables is developed in the project (as a part of the co-operation plan), and that the documents required for this, as well as the “Done” criteria are clarified.
  • They support the Product Owner: they develop an efficient method for the management of the backlog. They organize and conduct the sprint events.
  • They support the project participants and the business participants concerning the theory and practice of Scrum.
  • The support the team in the development of self-organization. They do not issue any direct orders concerning the performance of tasks.

Stakeholders

The stakeholders influence the course of the project, and make demands concerning the product to be delivered. It is the task of the Product Owner at the beginning of the project to identify the stakeholders and to involve them in the project depending on their concern (as a key user or even as an approver).

Project structure

In our experience, the alignment of the enterprise environment and the SCRUM methodology can be implemented as follows.

Pre-Sprint phase (Preparatory phase)

  • At the beginning of the project, the goal of the project/product, and the crucial information that are required for the successful development of the product are recorded by the Product Owner in the Product Vision.
  • Then, how the product evolves into the product outlined in the vision in the course of the planned releases is presented by them in the Product Roadmap: They break down the business goals and determine the features and requirements that have to be met in order for the goals to be achieved.
  • The resulting product of the Pre-Sprint phase is the initial Product Backlog.
    • The user demands and requirements are recorded in the Product Backlog, in the form of an epic or a user story.
    • All the changes that emerge in the form of features, functions, requirements, improvements, and corrections that should be performed in the future releases of the product are put into the Product Backlog.
    • The backlog items are ordered and classified into the planned releases by the Product Owner.
    • The Product Backlog changes continuously until the closure of the project.
  • In order to prepare a product of appropriate quality, it is necessary to determine requirements that clearly include the expectations inherently, and verifiable expectations concerning the product increment. The so-called “Done” criteria (Definition Of Done) serve this purpose.
    • The “Ready criteria(Definition Of Ready) typically contain the formal and substantial requirements concerning the backlog items. By complying with them, it can be ensured that the implementing team plans and delivers the solution based on high-quality requirements, thus the software to be completed also serves the goals accurately.
    • Deliberate “Done criteria” ensure that all product increments completed comply with the requirements concerning the whole of the product, thus situations in which a requirement concerning the whole of the product that is identified too late must be applied to the entire project at a high cost level can be avoided.

In the preparatory phase, the Scrum Team is formed, and negotiations between the Development Team and the Product Owner begin. The goal is to make the following conditions required for sprint initiation available by the end of the preparatory phase:

  • Preparation of the Product Vision
  • Preparation of the Product Roadmap
  • Identification of stakeholders (internal and external)
  • Preparation of the initial Product Backlog (identification of participants, recording epics), distribution of the frame of the story point on epic or feature level
  • Preparation of sprint-ready user stories enough for 3 sprints
  • Determination of READY and DONE criteria
  • Forming of the Scrum Team
  • Hardware and Software Infrastructure

The first spring may be initiated after the completion of the tasks associated to the preparatory phase.

Scrum cycle

  • The Scrum cycle starts with the first sprint planning.
    • During Sprint planning, the goal of the sprint is determined jointly by the Product Owner and the Development Team. The input of the work of the Development Team is provided by the sprint-ready Product Backlog items. Each user story planned to be in the sprint is provided with a story point by the Development Team, and a commitment is made by them concerning the scope of the sprint (sprint backlog).
    • In the second half of sprint planning, a plan is elaborated by the Development Team concerning the implementation of the sprint goal and the efficient performance of internal work. In order to prepare a product increment that can potentially go live at the end of each sprint, all tasks related to the product increment are performed by the team within the sprint.
    • As a result of planning, the user stories are broken down by the Development Team into smaller items, subtasks.
  • During the time of the sprint, the activities required for implementation, and the achievement of the goal of the sprint are synchronized, aligned by the Scrum Team at the Daily Scrum each day.
  • Simultaneously with implementation, the Product Owner works on the user stories of the subsequent sprints. At the Backlog Refinement (or Backlog Grooming) events, the Product Owner and the Development Team negotiate concerning the user stories written by the Product Owner. Based on the feedback, the Product Owner updates the backlog items and their order.
  • At the end of the sprint, at the Sprint Review (or Sprint Demo) event, the completed product increment is presented to the Product Owner by the Development Team.
    • If the product increment meets the acceptance criteria, and complies with the “Done” criteria, the Product Owner accepts the user stories completed.
    • The user stories that do not meet these criteria are put back into the Product Backlog.
  • At the end of every sprint, the Scrum Team examines the activities at the Sprint Retrospective event. This examination covers the methods applied, the co-operation between team members, and the quality of the product being prepared as well. For every deviation detected, the teams prepare a plan to solve the problem, which shall be monitored continuously.
  • The recommended length of a sprint is 1 week, the start and the end of which falls on the same day of the week throughout the project.

Release and product activation

  • Product release/activation is performed at the times determined in the Product Roadmap.
  • The release is preceded by detailed planning, as a result of which the Release Plan is prepared. Release planning assists the clients in the preparation for changes, and the organization of the activities required for the accommodation of the organization (modification of workflows, trainings).