# Zwischen Bosch Prozessen und agiler Webentwicklung – Eine Welt ohne Lastenheft
## Priorisierung von Nutzerbedürfnissen gegen Anforderungen eines Entwicklungspartners – Nur wie?

Im ersten Teil unserer Blogserie[Link], haben wir einige Herausforderungen angesprochen die in unserem Projekt gemeistert werden mussten. In diesem Beitrag wollen wir euch einen tieferen Einblick darüber geben, unter welchen Gesichtspunkten wir die diversen Anforderungen die an unser Projekt gestellt werden gegeneinander priorisieren.

Mit verschiedensten Stakeholdern wie: Nutzern, Kunden, Entwicklungspartnern, höherem Management und nicht zu letzt einem kreativem Team tragen wir eine gewaltige Menge an Anforderungen zusammen, was eine eindeutige und transparente Priorisierungsmethodik zwingend erforderlich macht.

Zu Beginn unseres Projektes fiel eine Priorisierung nicht schwer. Es gab ja kaum feste Anforderungen von außen. Abgesehen von ein paar technischen Notwendigkeiten haben wir potentielle und reale Nutzer gefragt, was sie am dringensten benötigen und die am häufigsten angefragten Punkte haben wir dann auch als erstes umgesetzt - erstmal logisch.
Mit der Zeit wurde der Aufschrei nach einer transparenteren Priorisierung der Anforderungen aber immer lauter und die Diskussionen bezüglich der „richtigen“ Priorisierung drangen vor allem auch mit Entwicklungspartnern und anderen Stakeholdern immer weiter in den Fokus.

**Was haben wir also gemacht um dem Herr zu werden?**

1. Anforderungssammlung
Alle Anfragen sammeln wir jetzt in unserem zentralen Ticketsystem „Helpspot“. Egal ob eine E-Mail an unsere Support-Adresse, ein erstelltes Ticket auf der [Support-Website] oder persönliche Rückmeldungen aus Fachrunden und Kundengesprächen; jede Anforderung wird in diesem System erfasst und initial von unserem First-Level-Support gesichtet. Wenn sich aus diesen Anfragen valide Anforderungen ergeben, landen diese ungefiltert in der "Inbox" unseres Entwicklungsrepositories.

2. Filterung
Bei Feature-Anfragen oder ähnlichen Anforderungen wird zuerst geschaut, ob es in die Vision und die Produktstrategie von Calponia passt und ob der Aufwand zu bewältigen ist. Der Löwenanteil der Anfragen schafft es dann aber auch von der „Inbox“ in den „Product Backlog“ und kann dort priorisiert werden.

3. Priorisierung
Auch wenn es mir als eingefleischter Vertreter von „User Centered Design“ schwer fällt so etwas zu schreiben aber: Nutzer-Bedürfnisse abzudecken reicht einfach nicht aus, wenn man als „Start-Up“ in unserem Konzern bestehen will. Themen wie Qualität, Vermarktbarkeit und andere wirtschaftliche Aspekte mussten dringend zu unserer bisherigen Priorisierung ergänzt werden. Deshalb haben wir eine Priorisierungsmatrix erstellt, welche alle folgenden Faktoren berücksichtigen soll:

- **Nutzerbedarf:** Wie oft wurde eine Funktion oder eine Optimierung angefragt und wie dringend ist die Anpassung für den Reporter?

- **Bezahlung:** Ist eine angefragte Funktion extern finanziert oder muss die Entwicklung vom Projekt getragen werden? - Komisch aber wahr: Nur weil Anpassungen extern finanziert werden, darf es nicht bedeuten, dass alle anderen Priorisierungsaspekte ignoriert werden.

- **Team Motivation:** Hat das Team eine besondere Motivation oder eine besondere Ablehnung gegenüber einem Thema?
Einige Old-School Manager mag es erstmal verwirren, dass soetwas Einfluss auf eine Priorisierung haben kann. Aber die Qualität und Effizienz der Entwicklung steigen erheblich wenn das Team auch Spaß daran hat und hinter dem steht was es da tun. Nicht umsonst rückt auch bei wissenschaftlicher-Erforschung von Erfolgsfaktoren diverser Teams das Thema "Motivation" immer weiter in den Fokus.

- **Vermarktbarkeit:** Der wirtschaftliche Faktor spielt ebenfalls eine wichtige Rolle. Denn wenn eine Funktion besonders gut zu verkaufen ist, weil sie uns beispielsweise am Markt einzigartig macht, muss auch an dieser Stelle eine höhere Priorisierung stattfinden.

- **Vision/Produktstrategie:** Um kein Feature-Monster zu generieren und einen klaren Produktfokus zu behalten ist es essenziell zu hinterfragen, wie gut die Anfrage zu der Produktstrategie passt. Niemand möchte ein Tool ohne klare Zielgruppe und ohne klaren Zweck entwickeln.

- **Aufwand-Nutzen/Aufwand-Zeit Verhältnis:** Das ist kein leicht zu setzender Parameter und erfordert wohl von allen Punkten die meiste Erfahrung. Dennoch ist es notwendig sich über den Aufwand für die Umsetzung einer Feature-Anfrage Gedanken zu machen. Dadurch können beispielsweise „Quick-Wins“ höher priorisieren werden, damit ein konstanter Fortschritt ersichtlich bleibt. Besonders in einem frühen Projekt Stadium ist es enorm wichtig, dass Nutzer regelmäßige Verbesserung wahrnehmen. Das steigert sowohl die Nutzer-, als auch die Teamzufriedenheit.

Anhand dieser sechs Faktoren wurde eine Befragung im Projektteam durchgeführt bei welcher jede Rolle vertreten war (nicht nur die Entwicklung, sondern auch Sales, Marketing, Management und UX-Design). Das Ziel war es herraus zu finden wie wichtig jeder einzelne Faktor für das gesamte Team ist.

Aus der Bewertung der sechs Priorisierungsfaktoren (auf eine Skala von "0" bis "10") inkl. der jeweiligen Gewichtung ergibt sich damit für jedes Feature in unserem Backlog ein fixer Zahlenwert welchen wir "Feature-Score" nennen. Die Items mit dem höhsten Feature Score werden dann auch als erstes in den Sprints eingeplant. Hier ist aber noch zu erwähnen, dass dieser Feature Score ein dynamischer Wert sein muss: Wenn ein Feature erneut angefragt wird, neue Stakeholder dazu kommen oder Sales Kollegen neue Erkenntnisse in Kunden Gesprächen gewonnen haben müssen die Bewertungen natürlich angepasst werden.

Als kleines Highlight haben wir dann auch ein Tool gefunden, welches sowohl alle Tickets aus unserem Entwicklungs-Repository auf diversen Boards, als auch unsere Priorisierungsmatrix inkl. "Feature Score" darstellen.
[ Screenshot Aha! Faktoren]

Abschließend möchte ich noch erwähnen, dass wir mit diesem System viele Diskussionen aus dem Weg räumen konnten, Nutzer und andere Stakeholder, welche nach mehr transparenz geschrien haben, befriedigen konnten und auch im Team für mehr Klarheit gesorgt haben.
Dennoch sehen wir immernoch Optimierungspotential: Anfragen von Nutzern bezüglich Dringlichkeit oder eine Übereinstimmung mit einer Produktvision nachträglich zu quantifizieren ist absolut nicht leicht und hier müssen Mittel her um diese Einschätzungen nicht subjektiv oder im worest case willkürlich erscheinen zu lassen. Zum Beispiel Vergleichtabellen oder eine Bewertung der Anfragen in einem kleinen "Gremium" könnten hier helfen.

**Im nächsten Blogbeitrag der Serie**
Im nächsten Beitrag zeigen wir euch, welche Phasen eine Feature-Anfrage im Detail durchläuft, und was dort genau passiert.

___

# Between Bosch processes and agile web development – A world without requirement contracts
## Prioritization of user needs against requirements of a development partner – But how?
_"I don't understand your prioritization!"_

Our project receives requirements from many different sources: users, customers, development partners, higher management, ideas from the team and many other sources. Of course, we cannot process all of these at the same time and have to prioritize them.

At the beginning of our project, prioritization was not difficult. There were hardly any fixed requirements from outside. Apart from a few technical necessities, we asked potential and real users what they needed. The most frequently requested features got the higher priority. This was the most plausible approach at first.
Over time, the cry for a more transparent prioritization of the requirements became louder and discussions about the "right" prioritization got more into focus.

**So what did we do to cope with it?**

1. Collection of requirements
We recently started collecting all requests in the central ticket system "Helpspot". No matter, if it is an e-mail to our support address, a ticket, or feedback from expert meetings and customer discussions; every request is tracked in this system and initially viewed by our first level support. If valid requirements result from these requests, they end up unfiltered in the "Inbox" of our development repository.

2. Filtering
Feature request or similar requirements are reviewed first if they fit into the vision and product strategy of Calponia and how much effort is needed to handle them. The lion's share of the requests make it into our "Inbox" and then into the "Product Backlog" and can be prioritized.

3. Prioritization
Even I, as a strong advocate of "User Centered Design", find it difficult to write something like this: User satisfaction is unfortunately not everything if you want to survive as a start-up in our Bosch group. Topics such as quality, team motivation, marketability and other economic aspects urgently had to contribute to our prioritization. Therefore, we created a prioritization matrix, which should consider all the following factors:

- **User need:** How often has a function or an improvement been requested and how urgent is the adaptation for the reporter?

- **Payment:** Is a requested function financed or not? Strange but true: Just because a request or an improvement is financed externally this does not mean that all other aspects of prioritisation are ignored.

- **Team motivation:** Does the team have a special motivation or a special dislike for a topic?
For some old-school managers this may seem confusing at first. However, the high qualitative and efficient output of satisfied employees speaks for itself. It is not without reason that "motivation" is more and more getting into the focus of science when researching the success factors of various teams.

- **Marketability:** The economic factor also plays an important role. If a function is particularly easy to market, for example because it makes us unique or because Sales can advertise it particularly well, high priority must also be given to this factor.

- **Vision/Product strategy:** In order to avoid generating a feature monster and to maintain a clear product focus, it is essential to question how well the request fits into the product strategy. Nobody wants to develop a tool without a clear target group and without a clear purpose.

- **Cost-benefit/cost-time ratio:** This is not an easy parameter to set. Nevertheless, it is necessary to think about the effort required to implement a feature request. For example, "quick wins" can be prioritized higher so that constant progress on the Calponia tool remains visible. Especially in a "prototype stage" it is very important that users notice regular improvements. This can increase user satisfaction as well as team satisfaction.

Based on these six factors, a survey was carried out which represents the entire project team. The aim was to determine a weight of the individual factors. This weight is multiplied by the factors to give the score for the feature.

The evaluation of the six prioritization factors (on a scale from "0" to "10") including the respective weighting results in a fixed numerical value for each feature in our backlog which we call "feature score". The items with the highest feature score will be scheduled first in the sprints. It should be mentioned that this feature score must be a dynamic value: If a feature is requested again, new stakeholders are added or sales colleagues have gained new insights in customer conversations, the scores must of course be adjusted.

Another highlight is that we found a tool which maps all tickets from our development repository on various boards as well as our prioritization matrix including the "feature score".

[ Screenshot ]

With this system we have been able to eliminate many discussions, satisfy users and other stakeholders who have been asking for more transparency, and also provide more clarity within the team.
Nevertheless, we still see potential for optimization: quantifying user requests regarding urgency or a match with a product vision is not easy at all. We need to find measures to ensure that these assessments do not appear subjective or, in the worst case, arbitrary. For example, comparison tables or an evaluation of the requests in a small "panel" could help here.

**In the next blog post of the series**
In the next article, we will show you which phases a feature request goes through in detail, and what exactly happens there.