Please enable JavaScript.

Coggle requires JavaScript to display documents.

. (Release Management (Release Intake (Suboptimal feedback loop between…

- - - - The prioritization and scope creep limits the efficiency of the development team: the team creates a breakdown of the work based on their availability and velocity. In the majority of sprints the backlog in changed and requests are added leading to a continuous (too) high work pressure
    - - Vicious circle of priority setting results in continuous delay: priority is generally given to the project with the (perceived) highest pressure (from the client) to deliver; other project get pushed back. As a consequence, the pressure to deliver increases for those customers of those ‘pushed back’ projects. As a result, the priorities of projects changes continuously
  - - - "* Product management receives limited feedback on the provided requirementes: what is build may differ from what is requested due to technical contraints, on most cases these changes are not communicated back to the requestor
        
        "We deliver what we can do, not what our customers are requesting"
    - - The planning, budget and content of a project are continuously redefined due to missing requirements: it often occurs (internal) requirements are not incorporated, for example the requirements for the platform teams, suppliers etc.
    - - The high level requirements do not specify exactly what to build: the development team interprets the purpose of the requirements and builds accordingly: increased risk of delivering something different than required
    - - The high level requirements provided consistently require clarification: for the majority of the high level requirements, it is necessary to go back to the requestor. Only when the high level requirements are clarified, the detailed requirements can be drafted
        
        "[P2] No clear information about the value/business case of the requests "
  - - - "Operations have insufficient influence in defining the content of a release "
    - - The roadmap has limited value to the company. the roadmap is created, updated every month and presented in a webinar to the business line and sales every 3-4 month.
        The roadmap is heavily dependent on the release planning and changes continuously
    - - Inaccurate perception that the roadmap is not existing: the roadmap is publicly accessible to all and shared during webinars
    - - Multiple internal clients are not aware of the existence of a roadmap: which prohibits them from preparing for the upcoming demand for their teams and required communication to the merchants
  - - - There is no view on the overlap, synergies, dependencies of the features and requirements etc. between the different projects in a release: projects are planned in silo’s, horizontally – meaning that they focus on their own budget, functionalities/requirements and timelines. They are clustered and allocated to releases
        
        "[P2] We don't have a release management or people assigned to this role. Not clear entity with authority to decide GO or NO GO to release in production"
        
        "[P1] The content definition of the releases take operational needs (and constraints) limitedly into account "
        
        "Request are coming to the team with multiple impacts in platforms, E2E project are not recognized by the requestor"
  - - - The technical release notes are currently 1) limitedly translated to business language, 2) if so, not written from the merchants’ perspective and 3) limitedly communicated to the merchants (or customer services). The customers, and customer services are therefore limitedly prepared for a release – often they are prepared last minute
        
        "Communication platform not ready when new product in launch"
        
        "Customers don't receive proper training and even the internal teams/partners are not trained"
        
        "Sometime we deliver new versions without informing CS"
        
        "Insufficient awareness of upcoming releases in the operational teams"
        
        "[P1] Information about new functionalities is shared late in the process, before the launch, and there's not enough time to update knowledge/scripts in CS"
    - - A service request of one customer is often implemented for all customers without consultation; there is no market research in to poll the needs or wants of the customer, the deployment of certain features is therefore mainly based on assumptions. Customers have no view on added or removed features.
        
        "[P3] Parallel releases result into increased effort when changes need to be"
        
        "New software releases which impact merchants are not (always) validated by the business"