In complex software projects, //SEIBERT/MEDIA follows the Scrum project management method. The following sections provide an overview of this project management method:

Scrum as project management method

Scrum is an iterative, incremental method of managing agile software projects.


PDCA (plan-do-check-act) is an iterative, four-stage problem solution process often used to optimize business processes. It is an integral part of good Scrum methodology.

The basic Scrum components:

Roles

  • Product Owner
  • Scrum Master
  •  Team

Artifacts

  • Product Backlog
  •  Selected Product Backlog
  •  Sprint Backlog
  • Burn down Chart
  • Impediment Backlog

Meetings

  •  Sprint Planning
    • Estimating and prioritizing
  • Daily Scrum
  • Sprint Review
  • Retrospective

Project coordination

Employees of both the contractor and client coordinate the project. The contractor coordinates the project implementation. The client coordinates the resources in charge of the technical specifications and technical acceptance tests.

The product owner of the client and the product owner proxy of the contractor are in charge of coordinating the overall project. The contractor and client plan the steps necessary to run the project smoothly.

The contractor provides the client with information that helps the client conduct project controlling and track the project status. Generally, this information includes:

  •  Daily automatic time records that are e-mailed to the employees of the client.
  •  Access to the contractor’s task management system. This is where the burn down charts, planned tasks and task statuses are listed.

Other important planning details are documented in the joint wiki system (e.g. contact information for contact persons, schedules, etc.).

Change request management, "If you want, changes can be done at no cost by replacing existing features with the features you want."

A change request is a feature or service provided by //SEIBERT/MEDIA. In this case, it is not part of the specifications or calculations mentioned above.

The client must provide the contractor with sufficient specifications for change requests. The contractor estimates how much effort will be required. Then the client classifies the function in the product backlog (priority). A CR can be incorporated without affecting the budget by replacing another function that has yet to be done or incorporated as an additional function by increasing the budget. An offer for the work order is submitted upon request. Unless agreed otherwise, change requests replace user stories that have yet to be realized.

Error tracking

Ideally, there is a joint system for tracking errors. The contractor can grant the client access to the JIRA task management system. In the system, errors can be recorded, managed and processed.

Alternatively, error lists (e.g. Excel) can be exchanged to track errors.

Cooperation services and provisions

  •  The customer provides the necessary technical requirements and is available for technical questions during the project.
  •  A representative of the contractor regularly participates in the planning meetings at the beginning and end of sprints, either in person or by telephone.
  •  The customer tests the completed functions in a timely manner and provides feedback on the status of the tests (success/error message).

Timeline

This is an example timeline for the project and gives you an idea how our process works:


The vision in user stories: the product backlog

The product backlog contains all features and requirements (user stories) necessary for realizing the product vision. The product backlog is derived from your service specifications.

Non-functional requirements and general work

The following elements are integral parts of a complex web project. Each element in the price overview contains one or more of the following services:

Establishing a technological platform

  •  Creating and configuring the basic elements of the development environment
    • Configuring the code repository SVN
  •  Setting up the continuous integration server and unit test suite
  •  General structure of the software system
    • Configuring Hibernate and DB migration (database abstraction stack)
    •  Installing the Oval Validation Framework (validation framework)
    • Ensuring the delivery of error messages
    • Preparing for use on the web server
    • Distributing and setting up test and production configurations (staging)
    • Common error pages (e.g. 404 error pages)
    • General server configuration and test stage set-up (Tomcat, Apache, MySQL, SSH)
    • Setting up the email service
    • Setting up additional services and frameworks
    • Implementing the GUI core
    • Implementing the back-end core

Conception, usability, coordination and design

  •  Functional analysis
  •  Competitor analysis
  •  Usability concept
  •  Layout
  •  Software architecture and UML diagrams
  •  Database design
  •  Selection of technology
  •  Coordination with the customer
  •  Team meetings and coordination of work
  •  Detailed specifications of the requirements

Tool and process infrastructure

  •  Setting up the bug tracking system
  •  Setting up the documentation system

Testing

  •  Unit tests and continuous integration server checks
  •  Functional tests as components of sprints
  •  Browser compatibility tests

We guarantee quality testing 

Always be on the safe side – continuous integration

The earlier you detect an error, the cheaper it is to fix. That’s why user stories always start off with a unit test, a short code, to make sure they are implemented correctly. Unit tests start whenever the source code is updated. When the tests fail, the causes are determined and removed. The contractor is responsible for ensuring the runability of unit tests. The client cannot be guaranteed access to the integration servers. Upon request, the contractor will provide information on the status of the integration server and display the live system in a desktop sharing session. Continuous integration guarantees the technology runs well and is stable.

Staying on track – sprint acceptance

The goal of every sprint is to realize the functional scope defined at the beginning of the sprint. Every function is described in a user story. Every user story contains acceptance criteria written in prose and defines what behavior is expected from the application and/or the function. Based on the acceptance criteria, the client accepts a function. At the start of the project, a “definition of done” should be formulated so everyone is in agreement about when a task is completely and correctly implemented.

Example for a “definition of done” in scrum projects

  •  All acceptance criteria are fulfilled.
  •  The implementation is complete and has been imported into the versioning system.
  •  A code review has been conducted or the code was written in pair programming.
  •  Unit tests have been performed.
  •  No critical bugs remain.

After a sprint, a client representative and the Scrum team coordinate with one another in a sprint review meeting. In this informal meeting, the team presents the completed user stories and the client provides feedback.

All new functions run on a test server. The customer can perform the acceptance tests during the following sprint. If the client finds any bugs, he documents them for the team. The bugs are scheduled to be fixed during the next sprint.

The review and acceptance criteria help keep the project “on track” and let you get feedback early on from the end user.

Ready for roll-out – system acceptance

Two sprints are dedicated to consolidating and accepting the system. These sprints take place after the last sprint in which new functions were implemented. During the consolidation sprint, a daily deployment on the test system is conducted. The client formally accepts the entirety of the realized functions in this period. Any defects that are detected are fixed as soon as possible so a new test can be conducted. Please note that no new functions or changes to existing functions can be implemented during the consolidation phase. In this stage, only defects are fixed.

  • No labels

This content was last updated on 11/10/2014.

This content hasn't been updated in a while. That doesn't have to be a problem. Some of our pages live for years without becoming obsolete.

Old content can be incorrect, misleading or outdated. Please get in contact with us via a form on this page, our live chat or via email with content@seibert.group if you are in doubt, have a question, suggestion, or want changes from us.