Requirement Management Process

The committee members can file requirements like everyone else but are not directly involved in the concrete realization of a desired functionality. Instead the committee sets boundaries by defining the overall goals for each release. The product increment as being the result of each release is approved or denied as a whole by the steering committee.

Term from the Scrum framework (see Scrum methodology). In Scrum this person is responsible for the definition and priorisation of the functional and non functional requirements of the product. She is responsible for shaping the vision together with the stakeholders and make sure that everybody building the product understands it (interface between stakeholders, sponsor and development team). The product owner has the competence to decide what should be build to create as much value as possible as quickly as possible. In Scrum requests for and issues of a product are managed in the so called backlog - the product owner is in charge of maintaining and prioritizing the backlog.

What does that mean for the OpenMDM working group? To get a successful product we think that is important to have such a product owner. We propose to choose an independent person and pay it using a service. Very often the engagement of a product owner is underestimated, since she is basically responsible for success or failure of the product, it is essential that this person has a enough time and knowledge. The OpenMDM product owner is responsible to collect and evaluate requests from the community (backlog management). She is also responsible to bundle and select the most valuable and efficient issues needed to reach the roadmap goals defined by the steering committee. Ideally the product owner escorts the development of packages/blocks of development - as she is the only person who can make quick decisions (short feedback cycle). The OpenMDM product owner reports to the steering committee and signs off the delivered product increments. She is the primary person which defines WHAT (functional requirements) is implemented. But it is important that the product owner is a good team player since the architecture committee and the quality committee define the HOW (non-functional requirements) of the product - and the team (service provider) is in charge to estimate the effort and to develop the requirements in the required quality in the simplest way with the least effort possible.

Discussion of the workshop 8-12-2014 Sven Wittig: Sven only sees the need of such a role in the collecting and bundling of the request from the community. The bundles/packages then are presented to the steering committee and provided they find a sponsor, are then implemented according to the architectural and quality guidelines. The escorting of the service provider is in the sole responsibility of the sponsor. Basically Sven Wittig assumes a bottom up (community driven) approach only.

Ulrich Bleicher, Andreas Benzig, Sibylle Peter and ???: While they see a possibility of a package product owner which is responsible for the implementation of such a package, they still think a OpenMDM product owner is needed to provide conformity and congruence for the product. They think it is necessary to have a top down (steering committee provides initial vision and roadmap for the product) as well as a bottom up approach

This discussion led to another interesting and important question, again from Sven Wittig: What is the product? Is it only a set of building blocks, loosely coupled, configurable and working together or is the product a system consisting of loosely coupled building blocks, which allows the community users to execute the most common shared use cases?

TODO: these questions (what is the product and which approach(es)) should be discussed in the steering committee asap.

The developers are responsible for the concrete implementation of the specified requirements. The team supports the product owner by pointing out costs, dependencies and risks linked with the realization of the requests. The developers are responsible for creating the shippable product at the end of each release iteration.

The committees elaborate standards and guidelines the developers commit themselves to adhere to. The committees reflect about and revise their regulations in regular intervals.They are responsible to define HOW the product is to be build and thus support the product owner in the definition of non-functional requirements.

A designated test team verifies that the implementation meets the defined acceptance criteria and does not breach any regulations. This test team does not replace the automated unit, integration and functional tests implemented by the development team.

Discussion 8-12-2014: It became obvious that this part of independant testing was neglected so far. The discussion led again to the importance of defined and automated test compatibility kits (TCK). We established, that there need to be at least two kits: 1. A functional TCK, specific for each component to test the functionality (WHAT) of a specified component. 2. A general TCK that is applied to all components to assure that the non-functional requirements (HOW) of architecture and quality are met.

New requirements can be filed by any person involved in planning, development and usage of the OpenMDM application. This includes the steering committee whose members want the application to provide a certain feature their employees are longing for as well as the developers who are adding functionality to the software and see needs for changes. Furthermore end-users from inside and outside the working-group are welcome to report their requirements and to inform about malfunctions or unexpected behaviour they experienced while using the application. Additionally the quality assurance/test team can file deficiencies they discover while testing the application. NOTE: As mentioned before, the product owner is responsible to evaluate and classify these new requests. As she is also responsible for prioritizing the present requirements the reporter has no influence on the realization order. Priority or severity flags set by the reporter are only considered as recommendations.

At first the requests are added to the Global Backlog, a free accessible reservoir for all requests. As the authors differ some of the requests might already describe in great detail what kind of addendum or fix is desired whereas others lack precision or just state a more general need. All kinds of granularity are thinkable.

The Product owner is in charge to review all requirements. The review has not explicitly done by the product owner himself. He may ask a developer for example to confirm a reported bug. Duplicate requests and those decided not to be implemented are closed immediately. Requests which are already implemented, invalid or just cannot be reproduced are declared resolved indicating the corresponding reason (e.g. fixed, invalid, worksForMe). The review can be seen as a constant clean-up task for the global backlog.

The steering committee (SC) of the OpenMDM working group and the designated product owner (PO) regularly come together to a Release Planning Meeting in order to discuss and define the overall, coarse-grained release goals for the next product release. Based on the agreements of this meeting the product owner is then responsible for evaluating if a certain requirement is relevant for the upcoming release. If the issue is of relevance for the next software release then it is moved to the next Release Backlog and its state switched to open.

The product owner contacts the initiator of the requirement request in order to fix its content and scope. Furthermore the PO has to confer with the steering committee to clarify the relevance of the requirement from the business’s point of view. In addition to that the product owner prioritizes the backlog items according to their importance to release success.

In regular Refinement Meetings the product owner and the developer team inspect the requirements. The first goal of the meetings is to establish a common understanding of the tasks at hand. Furthermore acceptance criteria need to be fixed the later implementation can be tested against. Last but not least impediments such as dependencies between items need to be identified. Thereby quality guidelines and architectural standards have to be considered. The developers estimate the realization effort i.e. the costs for each item. The farther the project advances i.e. the more experience the team gains and the more often an item is discussed the faster the estimation will narrow down to a reliable value.

NOTE:In the following paragraphs we assume an iterative or flow based agile approach is followed. However, as stated in the discussion from 8-12-2014, it is open to the sponsor and the development team how they are going to implement the issues in the release backlog. Nevertheless regarding the involvement of many players and stakeholders we strongly recommend following an agile approach, which includes frequent integration of product increment. This ensures that learning happens as early as possible. The later the integration of different parts and components, the later the learning the more expensive the corrective measures.

We recommend that content of the release backlog is realized in several iterations, also called sprints or several deliveries are made if using a flow system (Kanban). The term sprint is again derived from the Scrum framework describes a fixed work phase. The items regarded as 'ready for development', i.e. detailed enough, provided with acceptance criteria and not blocked by any known issues constitute the basis for the Planning Meeting which is held at the beginning of each iteration/regularly. During this meeting the product owner and the developer team check the available manpower, define the scope of the next sprint, split large items into feasible sub tasks and finalize their acceptance criteria. Moved to the Sprint Backlog the issue remains open till one developer with free capacity signs responsible for it.

The requirements then enter the realization stage and are declared as being in progress.

The specified release backlog items are developed according to the architecture and quality requirements and guidelines.

When at some point the implementation gets blocked this immediately has to be communicated to the sponsor. The solution of these impediments takes priority. In any case, if time runs out then the unfinished task is moved back to the release backlog → a story is either done or not done. This is another reason to work with an experienced product owner. She is familiar with story splitting and the smaller the items the bigger the chance they get done!

At the end of each sprint/iteration (but latest at the release if not followed an agile approach), the product owner, as representative of the stakeholders, approves the implementation and test result during a Sprint Review Meeting. Together with the Architecture and Quality Committee she checks that the software increment fulfills the functional and non-functional demands. If the product owner is not satisfied with the provided solution then the task is reopened and put back into the release backlog.

The product increment and the realized items are eventually handed over to the quality assurance and testing department. The testers check once again that all acceptance criteria are met and verifies that the implementation follows the agreed quality guidelines and architectural standards. The test team expresses its accordance by setting the item’s status to closed. In case deficiencies are diagnosed then new issues are added to the global backlog.

After the last sprint of a release has been concluded all then closed issues are integrated in a concrete release deliverable. This deliverable is presented by the product owner to the steering committee in a Sign-Off Meeting. The stakeholders, considering the formerly defined release goals, accept or deny the given solution. Only in the former case the solution is put into production. Either way the next iteration starts with another Release Planning Meeting.

As long as the last sprint for the current release scope has not been started unfinished tasks can be considered in the Refinement Meetings for the next iteration. It is the product owner’s responsibility to sort the tasks into the prioritized list of backlog items. In case the last sprint is already fixed then the task is, along with all remaining release backlog tasks, moved to the global backlog and considered again as new.

The clarification meetings have to take place regularly. Items can only be considered for a sprint planning meeting when they are clarified, described in detail and prioritized. It is crucial that the product owner prepares the designated next sprint’s items while the current sprint is still ongoing.

Lessons learned will be gathered in Sprint Retrospectives at the end of each sprint which may influence the realization process of upcoming sprints.

At any time, if an exceptional condition arises the product owner is allowed to notify the steering committee. In the following a non-exhaustive list of such conditions is provided:

In case a blocker issue is diagnosed in the productive system, then it is added to the current sprint backlog at once. The developer team and the product owner have to negotiate which other items are then dropped from the current sprint backlog and postponed till the next sprint.