Table 2 Business level issues

The business group describes short-term business goals and defines fixed business goals for separate development projects. The project business goals are not changed during development

Based on prioritised long-term roadmaps, the business team identifies and prioritises short-term requirements, selects the requirements for short-term releases and schedules these releases. Implementation can start once the content of the release backlog is ready for the first sprint

The business group is informed only through project steering group meetings

The release manager represents the business team in face-to-face meetings during release concept planning and development phases

Business value is seen only at the very end of the project, all at once

A large release backlog may be implemented by several projects that produce sub-releases for the entire release. One project may produce one or more sub-releases that can be considered project management milestones

The business group aims to complete and freeze specifications before go/no-go decisions on proceeding to software code design and testing

Release manager/ business team may reconsider the release backlog before each sprint

Business goals in documentations are unclear, lacking information and without adequate requirements prioritisation

Initial customer features for release backlog are created based on information in release roadmaps. Release manager creates a feature description document for each feature including initial requirements. Concept planning team members describe requirements implementation and relationships between features and the system. Workload is estimated

After accepting requirements prior to software design and testing, business group provides feedback only after project realisation

Minimum customer feature set (MCFS) to guide sprint iterations from business viewpoint. After each sprint, project teams present their results to release manager and business team